Canary release with Istio traffic splitting
Istio traffic management.
DestinationRule defines subsets by label, VirtualService routes weighted 90/10 to those subsets, then shift weights as the canary proves healthy.
What's really being asked
That you can separate pod scaling from traffic shaping and know which Istio resource does what. Canary in Istio is about request percentages, not replica ratios.
The full answer
Deploy two versions behind a single Kubernetes Service, distinguished by a label such as version stable and version canary. Create a DestinationRule for the host that declares two subsets mapping those labels. Create a VirtualService for the same host whose http route has two destinations, one to the stable subset with weight 90 and one to the canary subset with weight 10. Istio's sidecars then route ten percent of requests to canary independent of how many pods each has. To progress, edit the weights, for example to 50 and 50, then 0 and 100, watching success rate and latency between steps; finally remove the old deployment. You can also gate the canary by header for internal testers before opening it to a percentage.
The mistakes people make
Adjusting replica counts to approximate a ratio; that ties traffic share to pod count and breaks under autoscaling. Putting weights on the DestinationRule, which only defines subsets and policies, not routing weights. Forgetting that both deployments must share one Service and matching labels, otherwise subsets resolve to no endpoints.
What usually comes next
How do you automate weight progression? Tools like Flagger or Argo Rollouts drive the VirtualService based on metric analysis. How do you roll back instantly? Set canary weight to zero. How do you do header-based or sticky routing for a subset of users?
A concrete example
The reviews service has v1 and v2 deployments labeled accordingly behind one reviews Service. A DestinationRule defines subset v1 and v2. The VirtualService routes reviews traffic 90 to v1 and 10 to v2. After an hour of healthy v2 metrics you change weights to 50/50, then 0/100, and delete v1. At no point did you touch replica counts to control the split.
Interview question
You set up a 90/10 canary in Istio. Your platform team enables autoscaling on both deployments. Why does a weight-based VirtualService keep the split correct while a replica-count approach would not?
- a.Replica counts are more precise but require manual editing each scale event
- b.Both approaches are identical once a DestinationRule is present
- c.Autoscaling disables DestinationRule subsets, so only weights survive
- d.Weights are evaluated per request independent of pod count; replica ratios drift as pods scaleCorrect
Why? this is the answer
VirtualService weights apply per request regardless of how many pods exist, so autoscaling does not change the ratio. Approximating with replica counts couples the split to pod numbers, which autoscalers change unpredictably.
Just read this? Test yourself on what you have been reading.
Read the original → istio.io
- #istio
- #canary
- #traffic-management
- #virtualservice
- #kubernetes
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles