Shift Traffic Progressively with Istio

Split traffic between stable and canary with VirtualService weights, watch metrics, and promote or roll back by changing weights rather than redeploying.

~45 ministiokubernetesdeployment

Task

Route a percentage of traffic to a new version and adjust it based on observed metrics.

When to use this

A risky change is released to everyone at once because there is no cheap way to send a slice of traffic to a new version and observe it.

Prerequisites

Istio installed with sidecars or ambient mode
A metric backend for success and latency

Steps

1. Deploy the new version alongside the old with distinct labels.

Expected output: Both versions run and are addressable.

2. Use a VirtualService to split weighting between the two subsets.

Expected output: A chosen percentage reaches the canary.

3. Observe error rate and latency for the canary against the baseline.

Expected output: Promotion is data-driven.

4. Increase the canary weight steadily, or set it to zero to roll back.

istioctl analyze -n prod && kubectl get virtualservice app -o yaml

Expected output: Progression and rollback are a single config change.

Troubleshooting

Problem

Canary gets no traffic

Solution

Confirm subset labels match the pods and the gateway routes to the VirtualService.

Problem

Sticky sessions break

Solution

Weight-based splitting is per request; for stateful flows use consistent hashing or session affinity deliberately.

Limitations

Progressive delivery depends on reliable metrics; without good telemetry you are flying blind.
Weight splitting does not cover data migrations or stateful protocol changes that need more than traffic routing.

Context

Route a percentage of traffic to a new version and adjust it based on observed metrics. A risky change is released to everyone at once because there is no cheap way to send a slice of traffic to a new version and observe it.

Steps

Deploy the new version alongside the old with distinct labels. Expected: Both versions run and are addressable.
Use a VirtualService to split weighting between the two subsets. Expected: A chosen percentage reaches the canary.
Observe error rate and latency for the canary against the baseline. Expected: Promotion is data-driven.
Increase the canary weight steadily, or set it to zero to roll back. Expected: Progression and rollback are a single config change.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
spec:
  hosts: [app]
  http:
    - route:
        - destination: { host: app, subset: stable }
          weight: 90
        - destination: { host: app, subset: canary }
          weight: 10

Verify

Both versions run and are addressable.
A chosen percentage reaches the canary.
Promotion is data-driven.
Progression and rollback are a single config change.

Limits

Progressive delivery depends on reliable metrics; without good telemetry you are flying blind.
Weight splitting does not cover data migrations or stateful protocol changes that need more than traffic routing.