Alibaba Cloud Service Mesh:Implement canary release by user segment with traffic lanes and the Hash tagging plug-in

How it works

Three components work together to implement user-segment canary release:

The request flow works as follows:

1. A request arrives at the ingress gateway with an x-user-id header.

2. The Hash tagging plug-in computes hash(x-user-id) % 100 and sets x-asm-prefer-tag to either s1 (stable) or s2 (canary).

3. The VirtualService routes the request to the matching lane.

4. Within the lane, each service forwards the request to the next service in the call chain, preserving the lane assignment.

Prerequisites

Before you begin, make sure that you have:

• An ASM instance of version 1.18 or later with a cluster added. For more information, see Add a cluster to an ASM instance

• A Kubernetes managed cluster or ACS cluster. For more information, see Create an ACK managed cluster or Create an ACS cluster

• An ingress gateway deployed in the ASM instance. For more information, see Create an ingress gateway

• Sidecar injection configured for the target namespace

Sample application

This example uses a three-service call chain to demonstrate that lane routing is preserved across multiple hops, not just at the ingress:

• mocka (v1 only) -- entry point, forwards requests to mockb

• mockb (v1 only) -- middle service, forwards requests to mockc

• mockc (v1 and v2) -- terminal service with a canary version to test

Each service propagates the x-user-id header to downstream services, which enables trace context pass-through across the entire chain.

Step 1: Deploy the sample application

Create a file named sample.yaml with the following content, then apply it with the kubeconfig of the data plane cluster.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mocka-v1
  labels:
    app: mocka
    version: v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mocka
      version: v1
      ASM_TRAFFIC_TAG: v1
  template:
    metadata:
      labels:
        app: mocka
        version: v1
        ASM_TRAFFIC_TAG: v1
    spec:
      containers:
      - name: default
        image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing
        imagePullPolicy: IfNotPresent
        env:
        - name: version
          value: v1
        - name: app
          value: mocka
        - name: upstream_url
          value: "http://mockb:8000/"
        ports:
        - containerPort: 8000
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mockb-v1
  labels:
    app: mockb
    version: v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mockb
      version: v1
      ASM_TRAFFIC_TAG: v1
  template:
    metadata:
      labels:
        app: mockb
        version: v1
        ASM_TRAFFIC_TAG: v1
    spec:
      containers:
      - name: default
        image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing
        imagePullPolicy: IfNotPresent
        env:
        - name: version
          value: v1
        - name: app
          value: mockb
        - name: upstream_url
          value: "http://mockc:8000/"
        ports:
        - containerPort: 8000
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mockc-v1
  namespace: default
  labels:
    app: mockc
    version: v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mockc
      version: v1
      ASM_TRAFFIC_TAG: v1
  template:
    metadata:
      labels:
        app: mockc
        version: v1
        ASM_TRAFFIC_TAG: v1
    spec:
      containers:
      - name: default
        image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing
        imagePullPolicy: IfNotPresent
        env:
        - name: version
          value: v1
        - name: app
          value: mockc
        ports:
        - containerPort: 8000
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mockc-v2
  namespace: default
  labels:
    app: mockc
    version: v2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mockc
      version: v2
      ASM_TRAFFIC_TAG: v2
  template:
    metadata:
      labels:
        app: mockc
        version: v2
        ASM_TRAFFIC_TAG: v2
    spec:
      containers:
      - name: default
        image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing
        imagePullPolicy: IfNotPresent
        env:
        - name: version
          value: v2
        - name: app
          value: mockc
        ports:
        - containerPort: 8000

kubectl apply -f sample.yaml

Step 2: Create an Istio gateway

Create an Istio Gateway named ingressgateway in the istio-system namespace. This gateway accepts HTTP traffic on port 80 for all hosts. For more information, see Manage Istio gateways.

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:
        - '*'

Step 3: Create a lane group and lanes

Create a lane group

1. Log on to the ASM console. In the left-side navigation pane, choose Service Mesh > Mesh Management.

2. On the Mesh Management page, click the target ASM instance. In the left-side navigation pane, choose Traffic Management Center > Traffic Swimlane.

3. On the Traffic Swimlane page, click Create Swimlane Group and configure the following settings.

Parameter	Value
Name of Swim lane Group	canary
Ingress Type	ingressgateway
Lane Mode	Loose Mode
Pass-through Mode of Trace Context	Pass-through Trace Id
Trace ID Request Header	x-user-id
Request Routing Header	x-asm-prefer-tag -- enables the gateway to route traffic to different lanes based on request content and pass through the header in lane context
Swimlane Service	Select the target cluster, choose the default namespace, select mocka, mockb, and mockc, and click the icon to add them to the Selected pane

1. Click OK.

Create lanes s1 and s2

1. In the Traffic Rule Definition pane, click Create Swimlanes.

2. Create two lanes with the following settings.

Parameter	Lane s1 (baseline)	Lane s2 (canary)
Swimlane Name	s1	s2
Configure Service Tag -- Label Key	ASM_TRAFFIC_TAG	ASM_TRAFFIC_TAG
Configure Service Tag -- Label Value	v1	v2
Add Service	mocka(default), mockb(default), mockc(default)	mockc(default)

The following figure shows an example of configuring lane s1:

After both lanes are created, the lane group has the following layout:

Note

The first lane created in a lane group serves as the baseline lane by default. When a request targets a service that does not exist in the assigned lane, the request falls back to the baseline lane. For more information, see Modify the baseline lane in loose mode.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: swimlane-ingress-vs
  namespace: istio-system
spec:
  gateways:
  - istio-system/ingressgateway
  hosts:
  - '*'
  http:
  # Rule 1: Named user "jason" always goes to the canary lane
  - match:
    - headers:
        x-user-id:
          exact: jason
      uri:
        exact: /
    name: r2
    route:
    - destination:
        host: mocka.default.svc.cluster.local
        subset: s2
      fallback:
        target:
          host: mocka.default.svc.cluster.local
          subset: s1
      headers:
        request:
          set:
            x-asm-prefer-tag: s2
  # Rule 2: Hash-tagged canary traffic
  - match:
    - headers:
        x-asm-prefer-tag:
          exact: s2
      uri:
        exact: /
    name: r2
    route:
    - destination:
        host: mocka.default.svc.cluster.local
        subset: s2
      fallback:
        target:
          host: mocka.default.svc.cluster.local
          subset: s1
  # Rule 3: All other traffic goes to the baseline lane
  - match:
    - headers:
        x-asm-prefer-tag:
          exact: s1
      uri:
        exact: /
    name: r1
    route:
    - destination:
        host: mocka.default.svc.cluster.local
        subset: s1

Step 4: Deploy the Hash tagging plug-in

The Hash tagging plug-in is a WasmPlugin that runs at the ingress gateway. It hashes the x-user-id header value, computes hash % 100, and sets x-asm-prefer-tag based on configurable percentage ranges.

Create a file named wasm.yaml with the following content, then apply it with the kubeconfig of the ASM instance (not the data plane cluster).

apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
  name: hash-tagging
  namespace: istio-system
spec:
  imagePullPolicy: IfNotPresent
  selector:
    matchLabels:
      istio: ingressgateway
  url: registry-cn-hangzhou.ack.aliyuncs.com/acs/asm-wasm-hash-tagging:v1.22.6.2-g72656ba-aliyun
  phase: AUTHN
  pluginConfig:
    rules:
      - header: x-user-id         # Hash this header value
        modulo: 100                # Divide hash result by 100
        tagHeader: x-asm-prefer-tag  # Write the result to this header
        policies:
          - range: 20              # hash % 100 < 20 -> canary (20% of users)
            tagValue: s2
          - range: 100             # hash % 100 >= 20 -> stable (80% of users)
            tagValue: s1

kubectl apply -f wasm.yaml

Step 5: Verify the routing rules

export GATEWAY_ADDRESS=$(kubectl get svc -n istio-system | grep istio-ingressgateway | awk '{print $4}')

curl ${GATEWAY_ADDRESS} -H 'x-user-id: jason'

-> mocka(version: v1, ip: 10.0.0.15)-> mockb(version: v1, ip: 10.0.0.130)-> mockc(version: v2, ip: 10.0.0.133)

for i in 'bob' 'stacy' 'jessie' 'vance' 'jack'; do
  curl ${GATEWAY_ADDRESS} -H "x-user-id: $i"
  echo "   user $i requested"
done

-> mocka(version: v1, ip: 10.0.0.15)-> mockb(version: v1, ip: 10.0.0.130)-> mockc(version: v1, ip: 10.0.0.131)   user bob requested
-> mocka(version: v1, ip: 10.0.0.15)-> mockb(version: v1, ip: 10.0.0.130)-> mockc(version: v1, ip: 10.0.0.131)   user stacy requested
-> mocka(version: v1, ip: 10.0.0.15)-> mockb(version: v1, ip: 10.0.0.130)-> mockc(version: v2, ip: 10.0.0.133)   user jessie requested
-> mocka(version: v1, ip: 10.0.0.15)-> mockb(version: v1, ip: 10.0.0.130)-> mockc(version: v1, ip: 10.0.0.131)   user vance requested
-> mocka(version: v1, ip: 10.0.0.15)-> mockb(version: v1, ip: 10.0.0.130)-> mockc(version: v2, ip: 10.0.0.133)   user jack requested

Next steps

• Increase canary traffic gradually. Edit the WasmPlugin policies to shift more users to the canary lane. For example, change range: 20 to range: 50 to route 50% of users to the canary version.

• Promote to full release. When the canary version is validated, update lane s1 to include the new version and remove lane s2, or adjust routing rules to send all traffic to the updated baseline.

• Roll back. If problems are detected, set range: 0 for the canary lane tag value (s2) in the WasmPlugin, or delete the WasmPlugin entirely to stop all hash-based canary routing. Note that named-user routing (such as the x-user-id: jason rule in the VirtualService) remains active even without the WasmPlugin.