Skip to content
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

Open
saswata1989 opened this issue Jun 19, 2020 · 10 comments
Open

Flagger Istio Canary Deployment for dependent Microservices #631

saswata1989 opened this issue Jun 19, 2020 · 10 comments

Comments

@saswata1989
Copy link

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.

@stefanprodan
Copy link
Member

stefanprodan commented Jun 20, 2020

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.

@saswata1989
Copy link
Author

Thanks for the information.
what happens if there is no canary for one of the downstream service, will canary route to primary then?

@stefanprodan
Copy link
Member

Yes

@saswata1989
Copy link
Author

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?

@stefanprodan
Copy link
Member

The weight shifting happens at ingress (service A), the downstream canaries will receive the amount of traffic set at ingress.

@saswata1989
Copy link
Author

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?

@daverin
Copy link

daverin commented May 15, 2023

Is this functionality possible with AppMesh?

@koolay
Copy link

koolay commented May 30, 2023

Is it works with nginx? @stefanprodan

@sujeeth-alef
Copy link

@stefanprodan is this feature available for linkerd or nginx?

@Maksym-Perehinets
Copy link

@stefanprodan Hi, does this also works for canary release with nginx ingress, or it's only supported by Istio?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants