Canary release with Istio traffic splitting

WHAT THIS TESTS 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.

A GOOD ANSWER COVERS 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.

COMMON WRONG ANSWERS 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.

LIKELY FOLLOW-UPS 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?

ONE 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.