Master Full‑Chain Gray Release with Istio’s sourceLabels: A Step‑by‑Step Guide

Background

When product teams push a new version directly to production, any bugs can cause severe incidents and long recovery times, sometimes forcing a rollback. Multiple services may have new versions simultaneously, requiring traffic to be matched between versions. Istio’s gray traffic control can address these challenges.

Full‑Chain Gray Release and sourceLabel Principle

In a cluster with many microservices, each service may have several versions. If traffic is routed only between pods of the same version, a full‑chain gray release is achieved. For example, after the ingress gateway distributes traffic to appa v1 and v2, a pod of appa‑v1 will only call appb‑v1, while a pod of appa‑v2 will only call appb‑v2.

Istio’s sourceLabels in a VirtualService can match the source pod’s labels and forward the request to the corresponding backend subset. The following configuration shows how a pod labeled app: appa and version: v1 is routed to appb subset v1, and similarly for version v2:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: vs-appb
spec:
  hosts:
    - appb
  http:
    - route:
        - destination:
            host: appb
            subset: v1
      match:
        - sourceLabels:
            app: appa
            version: v1
    - route:
        - destination:
            host: appb
            subset: v2
      match:
        - sourceLabels:
            app: appa
            version: v2
    - route:
        - destination:
            host: appb
            subset: v1

After creating this VirtualService, every Envoy sidecar (including those of appa‑v1 and appa‑v2) will intercept traffic and select the appropriate backend based on the defined rules.

Operation Example

3.1 Deploy Deployments and Services

Deploy appa v1/v2, appb v1/v2, and the corresponding services.

apiVersion: v1
kind: Service
metadata:
  name: appa
  labels:
    app: appa
    service: appa
spec:
  ports:
  - port: 8000
    name: http
  selector:
    app: appa
---
apiVersion: v1
kind: Service
metadata:
  name: appb
  labels:
    app: appb
    service: appb
spec:
  ports:
  - port: 8000
    name: http
  selector:
    app: appb
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: appa-v1
  labels:
    app: appa
    version: v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: appa
      version: v1
  template:
    metadata:
      labels:
        app: appa
        version: v1
    spec:
      containers:
      - name: default
        image: swr.cn-north-4.myhuaweicloud.com/k8s-solution/go-http-sample:1.0
        env:
        - name: version
          value: v1
        - name: app
          value: appa
        - name: upstream_url
          value: "http://appb:8000/"
        ports:
        - containerPort: 8000
---
# (similar definitions for appb‑v1, appa‑v2, appb‑v2 omitted for brevity)

3.2 Route Ingress Gateway Traffic Proportionally to appa v1/v2

The gateway can split traffic by weight; the focus here is on sourceLabels, so detailed gateway configuration is omitted.

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: dr-appa
spec:
  host: appa
  subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: vs-gateway-appa
  namespace: istio-system
spec:
  gateways:
  - istio-system/app-gw
  - mesh
  hosts:
  - 192.168.1.106
  - appa.default.svc.cluster.local
  http:
  - delegate:
      name: vs-appa
      namespace: default
    match:
      - uri:
          prefix: /
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: vs-appa
spec:
  http:
  - match:
      - gateways:
        - istio-system/app-gw
    route:
      - destination:
          host: appa
          subset: v1
        weight: 10
      - destination:
          host: appa
          subset: v2
        weight: 90
  - match:
      - gateways:
        - mesh
    route:
      - destination:
          host: appa
          subset: v1
        weight: 100
      - destination:
          host: appa
          subset: v2
        weight: 0

3.3 Use sourceLabels to Direct Pods to Specific Backends

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: dr-appb
spec:
  host: appb
  subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: vs-appb
spec:
  hosts:
  - appb
  http:
  - route:
      - destination:
          host: appb
          subset: v1
    match:
      - sourceLabels:
          app: appa
          version: v1
  - route:
      - destination:
          host: appb
          subset: v2
    match:
      - sourceLabels:
          app: appa
          version: v2
  - route:
      - destination:
          host: appb
          subset: v1

3.4 Test Verification

Access the gateway IP and repeatedly curl the service; the response shows that appa‑v2 pods reach appb‑v2 and appa‑v1 pods reach appb‑v1, confirming full‑chain gray release.

Advantages and Disadvantages

Advantages : Leveraging native Istio sourceLabels provides clear, simple configuration for both L4 and L7 traffic routing across multiple versions.

Disadvantages : When a downstream service has only a single version, its outbound traffic loses version labels, causing label‑based routing to stop working.

If we deploy a service appc as two separate services ( appc‑v1 and appc‑v2) offering the same capability, sourceLabels can continue to be used for full‑chain routing.

© Huawei Cloud Community. All rights reserved by the original author.