Traffic management controls how requests reach application versions or service instances during releases. Basic canary routing can approximate weights through pod counts, while service meshes and load balancers provide finer control. section 8.3.4
Use traffic management to shape how canary versions receive requests:
- Route raw percentages, such as 5% to a new version and the remainder to the stable version. section 8.3.4
- Route requests by headers so selected features or users reach the canary. section 8.3.4
- Mirror requests to a canary while ignoring its responses, allowing production traffic patterns to be tested without serving canary responses. section 8.3.4
Mirroring traffic with Istio and Argo Rollouts
A Rollout can assign the canary a 25% scale weight, mirror 35% of matching GET requests to it, pause for ten minutes, and then remove the mirror route. The stable service continues serving production responses. section 8.3.4
Listing 8.29 Using Istio for advanced (weight-based) traffic split
apiVersion: argoproj.io/v1alpha1
kind: Rollout
spec:
...
strategy:
canary:
canaryService: notifications-service-canary
stableService: notifications-service-stable
trafficRouting:
managedRoutes:
- name: mirror-route
istio:
virtualService:
name: notifications-service-vsvc
steps:
- setCanaryScale:
weight: 25
- setMirrorRoute:
name: mirror-route
percentage: 35
match:
- method:
exact: GET
path:
prefix: /
- pause:
duration: 10m
- setMirrorRoute:
name: "mirror-route" # removes mirror based traffic route
Inspect the Rollout configuration for managed routes, Istio Virtual Services, request matching, mirroring, pausing, and route removal. section 8.3.4
