How to Implement Canary Releases with Istio: Step‑by‑Step Guide

Gray (canary) release, also known as a canary deployment, gradually shifts traffic from an old version to a new version by controlling the traffic proportion. For example, Service A may have version 1 and version 2 deployed simultaneously, initially routing 90% of requests to version 1 and 10% to version 2, then adjusting the split until the new version fully replaces the old one.

Key Characteristics of Canary Releases

Both versions coexist.

Traffic ratio can be adjusted in real time based on feedback.

Reduces the risk of total service outage.

Enables smooth upgrades and dynamic updates.

Using Istio for Canary Deployment

The following steps create the necessary Kubernetes resources and Istio configurations.

1. Create Canary Deployments

apiVersion: apps/v1
kind: Deployment
metadata:
  name: appv1
  labels:
    app: v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: v1
  template:
    metadata:
      labels:
        app: v1
    spec:
      containers:
      - name: nginx
        image: xianchao/canary:v1
        ports:
        - containerPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: appv2
  labels:
    app: v2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: v2
  template:
    metadata:
      labels:
        app: v2
    spec:
      containers:
      - name: nginx
        image: xianchao/canary:v2
        ports:
        - containerPort: 80

Apply the deployments:

kubectl apply -f deployment.yaml

2. Create Service

apiVersion: v1
kind: Service
metadata:
  name: canary
  labels:
    apply: canary
spec:
  selector:
    apply: canary
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

kubectl apply -f service.yaml

3. Create Istio Gateway

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: canary-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"

kubectl apply -f gateway.yaml

4. Define VirtualService and DestinationRule

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: canary
spec:
  hosts:
  - "*"
  gateways:
  - canary-gateway
  http:
  - route:
    - destination:
        host: canary.default.svc.cluster.local
        subset: v1
      weight: 90
    - destination:
        host: canary.default.svc.cluster.local
        subset: v2
      weight: 10
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: canary
spec:
  host: canary.default.svc.cluster.local
  subsets:
  - name: v1
    labels:
      app: v1
  - name: v2
    labels:
      app: v2

kubectl apply -f virtual.yaml

5. Verify Deployment

Obtain the Istio ingress gateway node port:

kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].nodePort}'

Assume the result is 30871. Send multiple requests to verify traffic split:

for i in `seq 1 100`; do curl 192.168.40.180:30871; done > result.txt

Inspect result.txt; about 90 lines should contain v1 and 10 lines v2, confirming the intended traffic distribution.

Conclusion

By defining separate Deployments, a Service, an Istio Gateway, a VirtualService with weighted routing, and a DestinationRule, you can perform a controlled canary rollout. The traffic percentages can be adjusted incrementally to ensure stability before fully promoting the new version.