Use traffic lanes in strict mode to manage end-to-end traffic - Alibaba Cloud Service Mesh

Traffic lanes in strict mode allow you to isolate a specific version or certain features of an application into a separate runtime environment. This approach is useful when you want to perform canary release for all services in a call chain or when you want to isolate an application version. By routing only traffic that meets the specified rules to new service versions, this approach ensures that the release is both reliable and controllable.

Prerequisites

A Service Mesh (ASM) instance of Enterprise Edition or Ultimate Edition is created and the version of the instance is 1.18.2.111 or later. For more information, see Create an ASM instance or Update an ASM instance.
Note
If the version of your ASM instance is 1.17.2.22 or later but earlier than 1.18.2.111, see Use lanes to manage traffic for information about traffic management.
The cluster is added to the ASM instance. For more information, see Add a cluster to an ASM instance.
An ASM ingress gateway named ingressgateway is created. For more information, see Create an ingress gateway.

An Istio gateway named ingressgateway is created in the istio-system namespace. For more information, see Manage Istio gateways.

Show the sample YAML code of the Istio gateway

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

Examples

In this example, three lanes (s1, s2, and s3) are created for the mocka, mockb, and mockc services. s1 represents the call chain of mocka v1, mockb v1, and mockc v1, and this pattern continues with s2 representing the call chain of mocka v2, mockb v2, and mockc v2, and s3 representing the call chain of mocka v3, mockb v3, and mockc v3.

Step 1: Deploy sample services

Enable automatic sidecar proxy injection for the default namespace. For more information about how to enable this feature, see Enable automatic sidecar proxy injection.
For more information about automatic sidecar proxy injection, see Enable automatic sidecar proxy injection.

Run the following commands to deploy sample services in a Container Service for Kubernetes (ACK) cluster:

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

Step 2: Create a lane group and lanes

Create a lane group.

Log on to the ASM console. In the left-side navigation pane, choose Service Mesh > Mesh Management.
On the Mesh Management page, click the name of the ASM instance. In the left-side navigation pane, choose Traffic Management Center > Traffic Lane.

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.
Lane Mode	Select Strict Mode.
Swimlane Services	Select the ACK cluster where you deployed sample services 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.

Create s1, s2, and s3 lanes and bind the s1 lane to version 1 (v1) of the sample services, the s2 lane to version 2 (v2) of the sample services, and the s3 lane to version 3 (v3) of the sample services.

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

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

Parameter

Description

Swimlane Name

Name the three lanes as s1, s2, and s3 respectively.

Configure Service Tag

Label Key: Select ASM_TRAFFIC_TAG.

Label Value: Select v1 for the s1 lane, v2 for the s2 lane, and v3 for the s3 lane.

The following figure shows the configurations of the s1 lane.

创建泳道

After the three lanes are created, you can view them in the Traffic Rule Definition section, as shown in the following figure. 创建泳道

A destination rule and a virtual service are automatically generated for each service in the lanes. You can choose Traffic Management Center > DestinationRule or VirtualService in the left-side navigation pane to view the destination rule or virtual service. For example, the following destination rule and virtual service are automatically created for the mocka service.

Expand to view the sample YAML code of the destination rule

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
    - labels:
        ASM_TRAFFIC_TAG: v3
      name: s3

Expand to view the sample YAML code of the virtual service

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

Create a traffic routing rule for each lane.

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.

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

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

Parameter	Description
Ingress service	Select mocka.default.svc.cluster.local.
Ingress traffic rules	Set the Name parameter to r1 and the realm name parameter to *.
Matching request URI	Set the Method parameter to Exact and the Content parameter to /mock.
Add Header Matching Rule	Click Add Header Matching Rule. Set Name to x-asm-prefer-tag, Method to Exact, and Content to s1, s2, and s3 respectively.

The following figure shows the configurations of the traffic routing rule for the s1 lane.

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

After a traffic routing rule is created, a virtual service is automatically generated for the lane. For example, the following virtual service is generated for the s1 lane.

Expand to view the sample YAML code of the virtual service

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

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

Obtain the public IP address of the ASM ingress gateway. For more information, see Step 2: Query the IP address of the ASM instance's ingress gateway.
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
```
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 s1 lane that you configured when you created the s1 lane in the substep 2 of Step 2.
```
for i in {1..100};  do curl   -H 'x-asm-prefer-tag: s1' http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;
```
  The system displays information similar to the following 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)
```
  The output indicates that 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 s2 lane that you configured when you created the s2 lane in the substep 2 of 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)
```
  The output indicates that 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 the service in the s3 lane.
  In the command, the value of x-asm-prefer-tag is s3, which is the name of the s3 lane that you configured when you created the s3 lane in the substep 2 of 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)
```
  The output indicates that traffic specified by the HTTP header x-asm-prefer-tag: s3 flows to the relevant services in the s3 lane. This meets expectations.

References

Traffic lanes have two modes: strict and permissive. For more information about the two modes and differences between them, see Overview of traffic lanes.
Traffic lanes in permissive mode can be used in more scenarios when end-to-end (E2E) pass-through request headers are used. For example, when only new versions of some services in a call chain are released, you can use traffic lanes in permissive mode to test these new versions. For more information, see Use traffic lanes in permissive mode to manage end-to-end traffic.
You can configure traffic lanes by specifying virtual services and destination rules. You can also use these rules to configure traffic shifting, which routes traffic to a version with a lower priority or an application with specific characteristics when the destination version or application is unavailable. For more information, see Use traffic rules to configure traffic lanes and traffic shifting.