[argoproj / rollouts-demo] Internal host request route not base on weight but pod count

[StyleTang]

Checklist:

• I've included steps to reproduce the bug.
• I've included the version of argo rollouts.

Describe the bug
Canary strategy (subset) has traffic route issue.

• For internal host it route base on pod count (has issue)
• For external host it route base on weight (as expect)

To Reproduce

I tested argoproj/rollouts-demo:examples/istio-subset, it is a canary(subset) rollout.

Just follow the read me

make release IMAGE_NAMESPACE=argoproj DOCKER_PUSH=false
kustomize build examples/istio-subset | kubectl apply -f -

Assume I only have 1 replica.

if I go to step 1:

      steps:
      - setWeight: 10
      - pause: {}         # pause indefinitely

Then env is:
canary pod count : 1
canary weight: 10 %
stable pod count : 1
stable weight: 90 %

If I use internal host, like http://istio-rollout.rollouts-demo-istio.svc.cluster.local/color, then the issue happens, the real traffic is 50% vs 50%, not base on weight but pod count.

apiVersion: v1
kind: Service
metadata:
  name: istio-rollout
spec:
  ports:
  - port: 80
    targetPort: http
    protocol: TCP
    name: http
  selector:
    app: istio-rollout

======================================================================

But if I use external host, it has no issue, like http://istio-rollout.apps.argoproj.io/color, the traffic dispatch works well. canary 10% vs stable 90%

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: istio-rollout-vsvc
spec:
  gateways:
  - istio-rollout-gateway
  hosts:
  - istio-rollout.apps.argoproj.io
  - istio-rollout.local

Expected behavior

Even use internal host like http://istio-rollout.rollouts-demo-istio.svc.cluster.local/color, the weight based traffic routing should still work.

Screenshots

Version

quay.io/argoproj/argo-rollouts:v1.6.4

Logs

rollout controller works, but traffic route has issue.

Message from the maintainers:

Impacted by this bug? Give it a 👍. We prioritize the issues with the most 👍.

[zachaller]

This is kind of by design and is how kubernetes services work, argo rollouts adjust the configuration on the virtual service which is why it works correctly there and is how traffic should flow. If you use the native k8s service you are going to be routed based on the service selectors.

[zachaller]

You should be able to internally also use the VirtualService so that traffic routes properly.

[StyleTang]

@zachaller
Could you have a look at this MR
It fix the issue I mentioned before.