Use traffic lanes in permissive mode in scenarios where trace IDs are passed through in traces - Alibaba Cloud Service Mesh

Traffic lanes in permissive mode allow you to isolate application versions. Traffic is routed to different lanes based on request routing headers and end-to-end (E2E) pass-through request headers. When services in a lane call each other, if the service to be called does not exist in the lane, requests are forwarded to the same service in the baseline lane. This feature ensures the integrity of call chains and simplifies traffic management. This topic describes how to use traffic lanes in permissive mode in scenarios where request routing headers are different from E2E pass-through request headers.

Important

Before you get started, make sure that you have read and understood the Use traffic lanes in permissive mode to manage end-to-end traffic topic and related content.

Scenario description

In this example, three lanes (s1, s2, and s3) are created and represent three versions of the mocka, mockb, and mockc services. s1 is the baseline lane and contains all three services of v1. s2 contains only the mocka and mockc services of v2. s3 contains only the mockb service of v3.

Step 1: Create a lane group and corresponding 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.
Istio gateway for an ingress gateway	Select ingressgateway.
Lane Mode	Select Permissive Mode.
Pass-through Mode of Trace Context	Select Pass Through Trace ID.
Trace ID Request Header	Enter my-request-id. This is because the sample services in this example transparently transmit the request header my-request-id in the trace.
Routing Request Header	You can specify this parameter based on your business requirements. The ASM gateway routes traffic to lanes and keeps the context of lanes based on the content of request routing headers. For this example, enter x-asm-prefer-tag.
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.

After a lane group is created, a traffic label is automatically generated for the lane group. You can choose Traffic Management Center > TrafficLabel in the left-side navigation pane to view the traffic label. For example, the following traffic label is automatically generated for the mocka service.

Show the YAML code of the traffic label

apiVersion: istio.alibabacloud.com/v1beta1
kind: TrafficLabel
metadata:
  labels:
    asm-system: 'true'
    provider: asm
    swimlane-group: test
  name: asm-swimlane-test-mocka
  namespace: default
spec:
  rules:
    - labels:
        - name: asm-label
          valueFrom:
            - '$getExternalInboundRequestHeader(x-asm-prefer-tag, my-request-id)'
  workloadSelector:
    labels:
      app: mocka

Create s1, s2, and s3 lanes and bind the s1 lane to the v1 version of the sample services, the s2 lane to the v2 version of the sample services, and the s3 lane to v3 version 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.
Add Service	For the s1 lane, select mocka(default), mockb(default), and mockc(default). For the s2 lane, select mocka(default) and mockc(default). For the s3 lane, select mockb(default).

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.

Note

By default, the first lane you create in a lane group is set as the baseline lane. When traffic is destined for services that do not exist in the other lanes, requests are forwarded to the baseline lane according to the fallback mechanism. For more information about how to change the baseline lane, see Change the baseline lane in permissive mode.

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.

Show 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

Show 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:
    - name: default
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: $asm-label
          fallback:
            target:
              host: mocka.default.svc.cluster.local
              subset: s1

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	For this example, select mocka.default.svc.cluster.local.
Ingress traffic rules	For this example, set the Name parameter to r1, r2, and r3 respectively for the three lanes. Set the realm name parameter to *.
Matching request URI	For this example, set the Method parameter to Exact and the Content parameter to /mock.

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 s2 lane.

Show 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-s2
  namespace: istio-system
spec:
  gateways:
    - istio-system/ingressgateway
  hosts:
    - '*'
  http:
    - match:
        - headers:
            x-asm-prefer-tag:
              exact: s2
          uri:
            exact: /mock
      name: r2
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s2
          fallback:
            target:
              host: mocka.default.svc.cluster.local
              subset: s1

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

Obtain the public IP address of the 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 substep 2 of Step 1.
```
for i in {1..100};  do curl   -H 'x-asm-prefer-tag: s1' -H'my-request-id: x000'$i 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)
```
  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 substep 2 of Step 1.
```
for i in {1..100};  do curl   -H 'x-asm-prefer-tag: s2' -H'my-request-id: x000'$i http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;
```
  Expected output:
```
-> mocka(version: v2, ip: 172.17.0.9)-> mockb(version: v1, ip: 172.17.0.129)-> 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. When traffic is destined for the mockb service that does not exist in the s2 lane, the traffic is forwarded to the mockb service in the s1 baseline lane according to the fallback mechanism. Then, the traffic is sent to the mockc service in the s2 lane as expected.
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 substep 2 of Step 1.
```
for i in {1..100};  do curl   -H 'x-asm-prefer-tag: s3' -H'my-request-id: x000'$i http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;
```
  Expected output:
```
mocka(version: v1, ip: 192.168.1.103)-> mockb(version: v3, ip: 192.168.1.120)-> mockc(version: v1, ip: 192.168.1.105)
```
  The output indicates that traffic specified by the HTTP header my-request-id: s3 flows to the relevant service in the s3 lane. This meets expectations. When traffic is destined for the mocka and mockc services that do not exist in the s3 lane, the traffic is forwarded to the mocka and mockc services in the s1 baseline lane according to the fallback mechanism.

Change the baseline lane in permissive mode

Note

You can change the baseline lane only in a permissive-mode lane group that contains at least two lanes.

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 the tab of the lane group for which you want to change the baseline lane. In the Traffic Rule Definition section, click the icon next to Baseline Lane.
Select the name of the baseline lane that you want to modify and click confirm edit.