Alibaba Cloud Service Mesh：Use lanes to manage traffic

Features

Canary release allows you to incrementally roll out new services or versions. For example, if you want to release a new version, you can first direct a portion of traffic to the version to test its functionality, and increase traffic after the functionality is verified.

End-to-end canary release primarily routes request traffic over different microservice call chains. You do not need to reconfigure your microservices for this purpose. Only a few rules are needed to build isolated environments for traffic from the gateway to services. End-to-end canary release facilitates the release of multiple services or multiple versions of a service at the same time. For more information, see Label traffic.

In this example, three lanes s1, s2, and s3 are deployed, and each lane contains three services mocka, mockb, and mockc. After the lanes are deployed in the ASM console, check whether the traffic is distributed among the lanes as expected.

Step 1: Deploy sample services

1. Enable automatic sidecar proxy injection for the default namespace.

   For more information, see 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.

2. Run the following commands to deploy sample services in the Container Service for Kubernetes (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

Step 2: Create a lane group and lanes

1. 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, set the parameters and click OK.

      Parameter	Description
      Name of swim lane group	For this example, enter test.
      Entrance gateway	Select ingressgateway.
      Swimlane Services	Select the desired ACK cluster from the Kubernetes Clusters drop-down list and select default from the Namespace drop-down list. Then, select mocka, mockb, and mockc in the service list, and click the icon to add the services to the selected section.

      After the configuration, the corresponding traffic label is generated.

      Show the YAML code of the traffic label

      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)
      

2. Create s1, s2, and s3 lanes and bind the s1 lane to v1 of the sample services, the s2 lane to v2 of the sample services, and the s3 lane to v3 of the sample services.

   This topic only describes how to create the s1 lane. You can create s2 and s3 lanes by using the same method.

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

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

      Parameter	Description
      Swimlane Name	For this example, enter s1. Note Requests whose headers contain the lane name in the format of 'x-asm-prefer-tag: lane name' are routed to the corresponding version of the services.
      Configure Service Tag	For this example, enter v1.
      Add Service	For this example, select the mocka(default), mockb(default), and mockc(default) services.

      

      After the three lanes are created, you can view them in the Traffic Rule Definition section, as shown in the following figure:

      Each time you create a lane, the system creates a destination rule. The following code provides an example of the destination rule that is created after you create the s1 lane:

      Show the sample YAML code of the destination rule

      apiVersion: networking.istio.io/v1beta1
      kind: DestinationRule
      metadata:
        creationTimestamp: '2023-05-29T09:06:09Z'
        generation: 3
        labels:
          asm-system: 'true'
          provider: asm
          swimlane-group: test
        name: trafficlabel-dr-test-default-mocka
        namespace: istio-system
        resourceVersion: '1310364657'
        uid: 7112ce64-0176-4ff3-b5f3-66263085****
      spec:
        host: mocka.default.svc.cluster.local
        subsets:
          - labels:
              ASM_TRAFFIC_TAG: v1
            name: s1
          - labels:
              ASM_TRAFFIC_TAG: v1
            name: v1
          - labels:
              ASM_TRAFFIC_TAG: v2
            name: v2
          - labels:
              ASM_TRAFFIC_TAG: v2
            name: s2
          - labels:
              ASM_TRAFFIC_TAG: v3
            name: v3
          - labels:
              ASM_TRAFFIC_TAG: v3
            name: s3
      

3. Create a traffic routing rule for each lane.

   This topic only describes how to create a traffic routing rule for the s1 lane. You can create traffic routing rules for the s2 and s3 lanes by using the same method.

   1. In the Traffic Rule Definition section of the Traffic Lane page, find the lane for which you want to create a traffic routing rule, and click Ingress traffic rules in the Actions column.

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

      This example assumes that the inbound request path of all the lane services is /mock, and the same traffic routing rule is configured for each lane.

      Parameter	Description
      Ingress service	For this example, select mocka.default.svc.cluster.local.
      Ingress traffic rules	For this example, set the Name parameter to r1 and the realm name parameter to *.
      Matching request URI	For this example, set the Method parameter to Exact and the Content parameter to /mock.

      After traffic routing rules are created, you can view them in the Traffic Rule Definition section, as shown in the following figure:

      Then, the system generates a virtual service. The following code provides an example of the virtual service:

      Show the sample YAML code of the virtual service

      apiVersion: networking.istio.io/v1beta1
      kind: VirtualService
      metadata:
        creationTimestamp: '2023-05-29T09:13:00Z'
        generation: 3
        labels:
          asm-system: 'true'
          istioGateway: ingressgateway
          provider: asm
        name: ingressgateway
        namespace: istio-system
        resourceVersion: '1310388638'
        uid: d60baa2f-3a12-472f-881a-15d21004****
      spec:
        gateways:
          - istio-system/ingressgateway
        hosts:
          - '*'
        http:
          - match:
              - headers:
                  x-asm-prefer-tag:
                    exact: s2
                uri:
                  exact: /mock
            name: swimelane-ingress-route-test-s2-rule2
            route:
              - destination:
                  host: mocka.default.svc.cluster.local
                  subset: s2
          - match:
              - headers:
                  x-asm-prefer-tag:
                    exact: s3
                uri:
                  exact: /mock
            name: swimelane-ingress-route-test-s3-rule3
            route:
              - destination:
                  host: mocka.default.svc.cluster.local
                  subset: s3
          - match:
              - headers:
                  x-asm-prefer-tag:
                    exact: s1
                uri:
                  exact: /mock
            name: swimelane-ingress-route-test-s1-rule1
            route:
              - destination:
                  host: mocka.default.svc.cluster.local
                  subset: s1
      apiVersion: networking.istio.io/v1beta1
      kind: VirtualService
      metadata:
        creationTimestamp: '2023-05-29T09:13:00Z'
        generation: 3
        labels:
          asm-system: 'true'
          istioGateway: ingressgateway
          provider: asm
        name: ingressgateway
        namespace: istio-system
        resourceVersion: '1310388638'
        uid: d60baa2f-3a12-472f-881a-15d21004****
      spec:
        gateways:
          - istio-system/ingressgateway
        hosts:
          - '*'
        http:
          - match:
              - headers:
                  x-asm-prefer-tag:
                    exact: s2
                uri:
                  exact: /mock
            name: swimelane-ingress-route-test-s2-rule2
            route:
              - destination:
                  host: mocka.default.svc.cluster.local
                  subset: s2
          - match:
              - headers:
                  x-asm-prefer-tag:
                    exact: s3
                uri:
                  exact: /mock
            name: swimelane-ingress-route-test-s3-rule3
            route:
              - destination:
                  host: mocka.default.svc.cluster.local
                  subset: s3
          - match:
              - headers:
                  x-asm-prefer-tag:
                    exact: s1
                uri:
                  exact: /mock
            name: swimelane-ingress-route-test-s1-rule1
            route:
              - destination:
                  host: mocka.default.svc.cluster.local
                  subset: s1
      

Step 3: Verify that the end-to-end canary release feature takes effect

1. Obtain the public IP address of the ASM gateway. For more information, see Step 2: Query the IP address of the ASM instance's ingress gateway in Integrate the cloud-native inference service KServe with ASM.

2. Run the following command to configure an environment variable.

   xxx.xxx.xxx.xxx is the IP address obtained in Substep 1.

   export ASM_GATEWAY_IP=xxx.xxx.xxx.xxx

3. Verify that the end-to-end canary release feature takes effect.

   1. Run the following command to access services in the s1 lane.

      In the command, the value of x-asm-prefer-tag is s1, which is the name of the lane that you configured when you created the lane in Step 2.

      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)

      Traffic specified by the HTTP header x-asm-prefer-tag: s1 flows to the relevant services in the s1 lane. This meets expectations.

   2. Run the following command to access services in the s2 lane.

      In the command, the value of x-asm-prefer-tag is s2, which is the name of the lane that you configured when you created the lane in Step 2.

      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)

      Traffic specified by the HTTP header x-asm-prefer-tag: s2 flows to the relevant services in the s2 lane. This meets expectations.

   3. Run the following command to access services in the s3 lane.

      In the command, the value of x-asm-prefer-tag is s3, which is the name of the lane that you configured when you created the lane in Step 2.

      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)

      Traffic specified by the HTTP header x-asm-prefer-tag: s3 flows to the relevant services in the s3 lane. This meets expectations.

(Optional) Step 4: Check the mesh topology

If you have enabled Mesh Topology in the ASM console, you can check the topology for the preceding requests. For more information, see Enable Mesh Topology to observe an ASM instance in the ASM console.