Alibaba Cloud Service Mesh:Use lanes for end-to-end canary release

Enable automatic sidecar proxy injection

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 name of the ASM instance. In the left-side navigation pane, choose ASM Instance > Global Namespace.

3. On the Global Namespace page, find the default namespace and click Enable Automatic Sidecar Injection in the Automatic Sidecar Injection column. In the Submit message, click OK.

For more information, see Enable automatic sidecar proxy injection.

Deploy the services

Deploy v1, v2, and v3 of the sample services in the ACK cluster:

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

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 name of the ASM instance. In the left-side navigation pane, choose Traffic Management Center > Traffic Lane.

3. On the Traffic Lane page, click Create Swimlane Group. In the Create Swimlane Group panel, configure the following parameters and click OK.

Parameter	Value
Name of swim lane group	test
Entrance gateway	ingressgateway
Swimlane Services	Select the ACK cluster from the Kubernetes Clusters drop-down list and select default from the Namespace drop-down list. Select mocka, mockb, and mockc in the service list, then click the icon to add them to the selected section

After you create the lane group, ASM generates a TrafficLabel resource:

apiVersion: istio.alibabacloud.com/v1beta1
kind: TrafficLabel
metadata:
  labels:
    asm-system: 'true'
    provider: asm
  name: asm-trafficlabel-global
  namespace: istio-system
spec:
  rules:
    - labels:
        - name: asm-label
          valueFrom:
            - $getLabel(ASM_TRAFFIC_TAG)   # Reads the ASM_TRAFFIC_TAG label from each pod

Create lanes

Create three lanes (s1, s2, s3) and bind each to the corresponding service version. The following steps show how to create the s1 lane. Repeat the same process for s2 (service tag: v2) and s3 (service tag: v3).

1. In the Traffic Rule Definition section of the Traffic Lane page, click Create swimlanes.

2. In the Create swimlanes dialog box, configure the following parameters and click OK.

After you create all three lanes, the Traffic Rule Definition section displays them as follows:

Each lane creation generates a DestinationRule. The following example shows the DestinationRule for the s1 lane:

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  labels:
    asm-system: 'true'
    provider: asm
    swimlane-group: test                              # Belongs to the "test" lane group
  name: trafficlabel-dr-test-default-mocka
  namespace: istio-system
spec:
  host: mocka.default.svc.cluster.local               # Target service
  subsets:
    - labels:
        ASM_TRAFFIC_TAG: v1                            # Lane s1 maps to version v1
      name: s1
    - labels:
        ASM_TRAFFIC_TAG: v1
      name: v1
    - labels:
        ASM_TRAFFIC_TAG: v2                            # Lane s2 maps to version v2
      name: v2
    - labels:
        ASM_TRAFFIC_TAG: v2
      name: s2
    - labels:
        ASM_TRAFFIC_TAG: v3                            # Lane s3 maps to version v3
      name: v3
    - labels:
        ASM_TRAFFIC_TAG: v3
      name: s3

Create ingress traffic rules

Create a traffic routing rule for each lane. The following steps show how to create a rule for the s1 lane. Repeat the same process for s2 and s3.

This example assumes all lane services share the inbound request path /mock.

1. In the Traffic Rule Definition section of the Traffic Lane page, find the target lane and click Ingress traffic rules in the Actions column.

2. In the Add drainage rule dialog box, configure the following parameters and click OK.

After you create traffic routing rules for all three lanes, the Traffic Rule Definition section displays them as follows:

ASM generates a VirtualService that routes requests based on the x-asm-prefer-tag header:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  labels:
    asm-system: 'true'
    istioGateway: ingressgateway
    provider: asm
  name: ingressgateway
  namespace: istio-system
spec:
  gateways:
    - istio-system/ingressgateway                      # Bind to the ingress gateway
  hosts:
    - '*'                                              # Match all hosts
  http:
    - match:
        - headers:
            x-asm-prefer-tag:
              exact: s1                                # Match requests tagged for lane s1
          uri:
            exact: /mock                               # Match the /mock path
      name: swimelane-ingress-route-test-s1-rule1
      route:
        - destination:
            host: mocka.default.svc.cluster.local      # Route to mocka
            subset: s1                                 # Use the s1 subset (version v1)
    - match:
        - headers:
            x-asm-prefer-tag:
              exact: s2                                # Match requests tagged for lane s2
          uri:
            exact: /mock
      name: swimelane-ingress-route-test-s2-rule2
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s2                                 # Use the s2 subset (version v2)
    - match:
        - headers:
            x-asm-prefer-tag:
              exact: s3                                # Match requests tagged for lane s3
          uri:
            exact: /mock
      name: swimelane-ingress-route-test-s3-rule3
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s3                                 # Use the s3 subset (version v3)

Get the gateway IP address

Get the public IP address of the ASM ingress gateway. For details, see Step 2 in Integrate the cloud-native inference service KServe with ASM.

Set the IP address as an environment variable. Replace <gateway-ip-address> with the actual public IP address.

export ASM_GATEWAY_IP=<gateway-ip-address>

Test each lane

Send 100 requests to each lane and verify that traffic stays within the expected service versions.

Lane s1 (expected: all v1):

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

Expected output:

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

All three services return v1, confirming that requests tagged with x-asm-prefer-tag: s1 route exclusively through the s1 lane.

Lane s2 (expected: all v2):

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

Expected output:

-> mocka(version: v2, ip: 172.17.0.9)-> mockb(version: v2, ip: 172.17.0.126)-> mockc(version: v2, ip: 172.17.0.128)

Lane s3 (expected: all v3):

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

Expected output:

-> mocka(version: v3, ip: 172.17.0.132)-> mockb(version: v3, ip: 172.17.0.127)-> mockc(version: v3, ip: 172.17.0.69)

Troubleshoot routing issues

If any request returns a mismatched version, check the following: