-
Notifications
You must be signed in to change notification settings - Fork 743
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Flagger Istio Canary Deployment for dependent Microservices #631
Comments
Chaining canaries can be done with source labels matching. Source labels have been implemented in Flagger v1.0.0 #594. Service A: kind: Canary
metadata:
name: frontend
spec:
provider: istio
service:
gateways:
- mesh
analysis:
stepWeight: 10
maxWeight: 100 Service B: kind: Canary
metadata:
name: backend
spec:
provider: istio
service:
gateways:
- mesh
analysis:
iterations: 10
match:
- sourceLabels:
app: frontend When both service A and B are under analysis, traffic is split at service A and the calls from A canary are routed to B canary, while calls from A primary are routed to B primary. |
Thanks for the information. |
Yes |
Can you please let me know how does iteration work and if we can add step weight in that so that during canary deployment we can use the weighted routing with source labels? |
The weight shifting happens at ingress (service A), the downstream canaries will receive the amount of traffic set at ingress. |
What happens if the Service A does not have a canary? How does the weight shifting happen for the downstream canaries then? In that case can we set stepWeight along with source labels? |
Is this functionality possible with AppMesh? |
Is it works with nginx? @stefanprodan |
@stefanprodan is this feature available for linkerd or nginx? |
@stefanprodan Hi, does this also works for canary release with nginx ingress, or it's only supported by Istio? |
Can you please let me how can we can perform Istio Canary deployment with Flagger for dependent micro services.
Suppose we have 2 micro services A and B.
Microservice A is invoking svc B using an environment variable (whose value is B.<namespace_name>.svc.cluster.local:8080) in the deployment spec of A.
Now if we have canary deployment, how do we make sure any call from A -canary pod goes to B canary Pod and NOT B -primary.
And if we dont have any B-canary, any call from A-canary should go to B-primary.
Is there a way when flagger creates the canary deployment spec it replaces any environment variable in it with the canary svc url of the downstream microservice.
Above applies if we have 5 more dependent downstream microservices.
The text was updated successfully, but these errors were encountered: