Mastering Loose‑Mode Traffic Swimlanes in Alibaba Cloud Service Mesh (ASM)

Overview

The article explains how to use ASM’s loose‑mode traffic swimlane to achieve full‑link gray release without modifying application code. In loose mode a baseline swimlane contains all services, while other swimlanes may include only a subset. Requests that target a service missing from the current swimlane are automatically routed to the baseline.

Prerequisites

ASM Enterprise or Premium instance version 1.18.2.111 or later.

Cluster added to the ASM instance.

Ingress gateway named ingressgateway created in the istio-system namespace.

Gateway rule for ingressgateway configured (see code snippet below).

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

Deploy Sample Services

Enable automatic Sidecar injection for the default namespace, then apply three mock services representing three versions of a call chain:

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 Swimlane Group

In the ASM console, navigate to Service Mesh → Mesh Management → Traffic Management Center → Traffic Swimlane and create a swimlane group named test. Set the following options:

Ingress gateway: ingressgateway Swimlane mode: Loose Request‑header settings: both the traffic‑steering header and the chain‑propagation header are my-request-id Swimlane services: select mocka, mockb, mockc in the default namespace.

The first swimlane created becomes the baseline swimlane.

Create Swimlanes

Create three swimlanes (s1, s2, s3) and bind them to the three mock versions (v1, v2, v3). Configure the service label ASM_TRAFFIC_TAG with values v1, v2, v3 respectively. Service selection per swimlane:

s1 : mocka, mockb, mockc

s2 : mocka, mockc

s3 : mockb

After creation, ASM automatically generates a DestinationRule for each swimlane, e.g. for mocka:

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:
  - labels:
      ASM_TRAFFIC_TAG: v1
    name: s1
  - labels:
      ASM_TRAFFIC_TAG: v2
    name: s2

ASM also creates a VirtualService for each swimlane, routing traffic based on the header value.

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:
    - headers:
        my-request-id:
          exact: s1
    route:
    - destination:
        host: mocka.default.svc.cluster.local
        subset: s1
    fallback:
      target:
        host: mocka.default.svc.cluster.local
        subset: s1
  - match:
    - headers:
        my-request-id:
          exact: s2
    route:
    - destination:
        host: mocka.default.svc.cluster.local
        subset: s2
    fallback:
      target:
        host: mocka.default.svc.cluster.local
        subset: s1
  - match:
    - headers:
        my-request-id:
          exact: s3
    route:
    - destination:
        host: mocka.default.svc.cluster.local
        subset: s3
    fallback:
      target:
        host: mocka.default.svc.cluster.local
        subset: s1

Create Routing (Steering) Rules

For each swimlane, add a routing rule that matches the /mock URI and uses the header my-request-id (or x-asm-prefer-tag in the first scenario) to select the lane. Example rule for swimlane 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:
        my-request-id:
          exact: s1
      uri:
        exact: /mock
    name: r1
    route:
    - destination:
        host: mocka.default.svc.cluster.local
        subset: s1

Verification

Obtain the public IP of the ASM gateway, export it as ASM_GATEWAY_IP, then issue curl commands with the appropriate header to see which version of each mock service is invoked. Example for swimlane s1:

for i in {1..100}; do \
  curl -H 'my-request-id: s1' http://${ASM_GATEWAY_IP}/mock; \
  echo ''; sleep 1; done

Expected output shows calls to mocka, mockb, mockc all at version v1. Similar commands with my-request-id: s2 or my-request-id: s3 demonstrate that traffic is correctly routed to the corresponding swimlane, and that missing services fall back to the baseline swimlane.