Practice vocabulary for canary deployments using a service mesh: VirtualService traffic splitting, weighted routes, rollbacks, and Istio traffic management.
0 / 5 completed
1 / 5
When an Istio VirtualService routes 5% of incoming traffic to a new version of a service, this is described as:
The VirtualService splits 5% of traffic to the canary — Istio's VirtualService uses weighted routing rules to control traffic distribution between service versions.
2 / 5
When a canary deployment gradually shifts more traffic to the new version over time rather than all at once, this is called:
The weighted route transitions traffic gradually — start at 5%, increase to 20%, 50%, 100% as confidence grows. The VirtualService weights are updated incrementally.
3 / 5
When issues are detected in the canary version and all traffic is immediately sent back to the original version, this is called:
The canary rollback changes the weight to 0% — updating the VirtualService weight to zero instantly stops sending traffic to the canary version.
4 / 5
One advantage of using a service mesh for canary deployments is that you can shift traffic without changing the deployment itself. This is described as:
The mesh handles traffic shifting without redeploying — Istio can change traffic distribution by updating routing rules, no new pods or deployments needed.
5 / 5
The Istio feature used to define traffic routing rules such as canary weights and version-based routing is called:
We use Istio traffic management for canary releases — specifically VirtualService (routing rules) and DestinationRule (subsets) work together to implement canary patterns.