Master Full‑Chain Gray Release with ASM Traffic Lanes: Strict Mode Walkthrough

Overview

Gray release is a common technique for rolling out new versions of an application by dynamically shifting traffic between stable and candidate versions, allowing verification of functionality and reliability before fully switching over. In cloud‑native environments, services are decomposed into multiple Kubernetes workloads, making full‑chain traffic control essential.

Challenges in Full‑Chain Traffic Management

High rule complexity : Each service requires its own VirtualService and DestinationRule, increasing the chance of misconfiguration.

Low flexibility : Simple rule adjustments cannot satisfy scenarios such as releasing only a subset of services in a chain.

ASM Traffic Lane Capability

Simple configuration : A small set of governance rules can create isolated environments (lanes) from the gateway to the entire backend.

Supports diverse full‑chain requirements : Strict and loose lane modes address different use cases and constraints.

Strict Mode vs Loose Mode

In strict mode , every lane contains all services in the call chain, requiring no changes to the application. In loose mode , only a baseline lane must contain the full chain; other lanes may omit services, and requests are forwarded to the baseline lane when a target service is missing. Loose mode requires a transitive request header and an additional routing header.

Demo: Using Strict Mode for Full‑Chain Gray Release

Prerequisites

ASM Enterprise or Premium instance (v1.18.2.111+).

ACK cluster added to the ASM instance.

Ingressgateway named ingressgateway created.

Gateway rule for ingressgateway in the istio-system namespace.

Deploy Example Services

kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v1/mock-v1.yaml
kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v2/mock-v2.yaml
kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v3/mock-v3.yaml

Create Lane Group and Lanes

In the ASM console, create a lane group named test and three lanes s1, s2, s3 corresponding to the v1, v2, v3 versions of the mock services.

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  labels:
    asm-system: 'true'
    provider: asm
    swimlane-group: test
  name: trafficlabel-dr-test-default-mocka
  namespace: istio-system
spec:
  host: mocka.default.svc.cluster.local
  subsets:
    - name: s1
      labels:
        ASM_TRAFFIC_TAG: v1
    - name: s2
      labels:
        ASM_TRAFFIC_TAG: v2
    - name: s3
      labels:
        ASM_TRAFFIC_TAG: v3

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  labels:
    asm-system: 'true'
    provider: asm
    swimlane-group: test
  name: trafficlabel-vs-test-default-mocka
  namespace: istio-system
spec:
  hosts:
    - mocka.default.svc.cluster.local
  http:
    - match:
        - sourceLabels:
            ASM_TRAFFIC_TAG: v1
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s1
    - match:
        - sourceLabels:
            ASM_TRAFFIC_TAG: v2
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s2
    - match:
        - sourceLabels:
            ASM_TRAFFIC_TAG: v3
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s3

Configure Ingress Routing Rules

Entry service : mocka.default.svc.cluster.local Routing rule name : r1, host * URI match : exact /mock Header match : x-asm-prefer-tag exact value set to the lane name (e.g., s1).

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  labels:
    asm-system: 'true'
    provider: asm
    swimlane-group: test
  name: swimlane-ingress-vs-test-s1
  namespace: istio-system
spec:
  gateways:
    - istio-system/ingressgateway
  hosts:
    - '*'
  http:
    - match:
        - headers:
            x-asm-prefer-tag:
              exact: s1
          uri:
            exact: /mock
      name: r1
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s1

Validate the Full‑Chain Gray Release

Obtain the ASM gateway IP and set it as an environment variable. export ASM_GATEWAY_IP=xxx.xxx.xxx.xxx Send traffic with the lane header to verify each lane.

for i in {1..100}; do curl -H 'x-asm-prefer-tag: s1' http://${ASM_GATEWAY_IP}/mock; echo ''; sleep 1; done;

Expected output for lane s1:

-> mocka(version: v1, ip: 172.17.0.54) -> mockb(version: v1, ip: 172.17.0.129) -> mockc(version: v1, ip: 172.17.0.130)

Repeat the curl command with s2 and s3 headers; the responses should show the corresponding v2 and v3 versions, confirming that traffic is correctly routed to the selected lane.

Conclusion

The article outlines the challenges of full‑chain traffic management in cloud‑native applications and demonstrates how ASM traffic lanes simplify rule configuration, support both strict and loose modes, and enable reliable gray releases across an entire service call chain.