-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Description
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 indefinitelyThen 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.localExpected 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 π.