Practical problems with canary rollout

Question

I'm looking at using canary deployments in Istio but it seems it randomly distributes requests to new and old versions based on a weighting. This implies a user in the business could see one behaviour one minute and different behaviour the next minute & people within teams could experience different behaviour to each other. For this reason it seems if I want consistent behaviour for a user or team I need to build my own roll-out mechanism where I can control who moves on to the new service version.

Am I correct or am I misunderstanding how Istio canary rollout works?

Answer 1

If you do a basic traffic distribution by weight, you are correct.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: helloworld
spec:
  hosts:
    - helloworld
  http:
  - route:
    - destination:
        host: helloworld
        subset: v1
      weight: 90
    - destination:
        host: helloworld
        subset: v2
      weight: 10

Here 10 % of the traffic is routed to v2 randomly. Any request might call a different version.

But you can do more sophisticated routing.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: helloworld
spec:
  hosts:
    - helloworld
  http:
  - match:
    - headers:
        group:
          exact: testing
    route:
    - destination:
        host: helloworld
        subset: v2
  - route:
    - destination:
        host: helloworld
        subset: v1

Now there are two routes:

• The users with a header group=testing will be send to v2
• All other users will be send to v1

The header in this example could be set in the frontend based on the user, so backend requests for that user will call v2.

Or you could set a cookie for a specific group and route them to a different frontend by using something like:

- match:
    - headers:
        cookie: 
           [...]

There are multiple match criteria, including headers, queryParams and authority.