Use permissive mode traffic lanes with propagated headers - Alibaba Cloud Service Mesh

You can use traffic lanes in permissive mode to achieve application version isolation. By designating an E2E pass-through request header as the request routing header, you can use the header's value to route traffic to swimlanes. When services within a swimlane call each other, if a destination service does not exist in the current swimlane, the request is forwarded to the baseline lane. This ensures call chain integrity and simplifies traffic management.

Important

Before you begin, ensure you have read and understood Use permissive mode traffic lanes to manage end-to-end traffic and its related content.

Scenario overview

This example uses three services, mocka, mockb, and mockc, to create three swimlanes (s1, s2, and s3) that represent three versions of a service call chain. The s1 swimlane is the baseline lane and contains all three services. The s2 swimlane contains only the mocka and mockc services. The s3 swimlane contains only the mockb service. In this scenario, both the E2E pass-through request header and the request routing header are set to my-trace-id.

Step 1: Create a swimlane group and swimlanes

Create a swimlane 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, configure the parameters and click OK.

Parameter	Description
Name of swim lane group	In this example, set the name to test.
Entrance gateway	Select ingressgateway.
Lane Mode	Select Permissive Mode.
Pass-through Mode of Trace Context	Select Pass Through Custom Header.
E2E Pass-through Request Header	Set this to `my-trace-id`.
Swimlane service	Select the target Kubernetes cluster and the default `namespace`. In the list of services, select mocka, mockb, and mockc. Click the icon to move them to the selected area.

Create the s1, s2, and s3 swimlanes and bind them to the v1, v2, and v3 versions, respectively.

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

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

Parameter	Description
Swimlane Name	Set the names of the three `swimlanes` to s1, s2, and s3, respectively.
Configure Service Tag	Label Key: Set to ASM_TRAFFIC_TAG. Label Value: Set to v1, v2, and v3 for the `s1`, `s2`, and `s3` `swimlanes`, respectively.
Add Service	For the `s1` `swimlane`: Select mocka(default), mockb(default), and mockc(default). For the `s2` `swimlane`: Select mocka(default) and mockc(default). For the `s3` `swimlane`: Select mockb(default).

After the three swimlanes are created, the result is displayed. By default, the first swimlane you create in a group becomes the baseline lane. You can change the baseline lane. When traffic is sent to a service that does not exist in another swimlane, the fallback mechanism forwards the request to the baseline lane. For more information about how to change the baseline lane, see Modify the baseline lane. On the Traffic Rule Definition page, the Baseline Lane is set to s1, and the Ingress Type is ASM Gateway (ingressgateway).

After you create the three swimlanes, Alibaba Cloud Service Mesh automatically generates a DestinationRule and a VirtualService for each service in the swimlane group. You can view them by choosing Traffic Management Center > DestinationRule or Virtual Service in the navigation pane on the left. For example, ASM automatically creates the following DestinationRule and VirtualService for the mocka service.

Sample DestinationRule YAML

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

Sample VirtualService YAML

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:
        - headers:
            my-trace-id:
              exact: s1
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s1
          fallback:
            target:
              host: mocka.default.svc.cluster.local
              subset: s1
    - match:
        - headers:
            my-trace-id:
              exact: s2
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s2
          fallback:
            target:
              host: mocka.default.svc.cluster.local
              subset: s1
    - match:
        - headers:
            my-trace-id:
              exact: s3
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: s3
          fallback:
            target:
              host: mocka.default.svc.cluster.local
              subset: s1

Create traffic routing rules for the three swimlanes.

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

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

This example assumes that the ingress API for all swimlane services is /mock. Therefore, you configure the same traffic routing rule for each swimlane.

Parameter	Description
Ingress service	Select mocka.default.svc.cluster.local.
Ingress traffic rules	For the `traffic routing rules` of the three `swimlanes`, set the Name to r1, r2, and r3, respectively. Set the realm name to *.
Matching request URI	Set Method to Exact and Content to /mock.

After you create the traffic routing rules for the three swimlanes, the result is displayed. In addition to the exact URI match, each rule includes a Headers match condition: the header name is my-trace-id, the match type is exact, and the match values for the s1, s2, and s3 swimlanes are s1, s2, and s3, respectively. The Baseline Lane is set to s1.

After you create the rules, ASM automatically generates a VirtualService that defines the traffic routing rule for each swimlane. For example, ASM generates the following VirtualService for the s2 swimlane.

Sample VirtualService YAML

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:
            my-trace-id:
              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 E2E canary release

Obtain the public IP address of the ASM ingress gateway. For more information, see Obtain the IP address of an ingress gateway.
Run the following command to set an environment variable.

In the command, xxx.xxx.xxx.xxx is the IP address that you obtained in the previous step.
```
export ASM_GATEWAY_IP=xxx.xxx.xxx.xxx
```
Verify the E2E canary release.
1. Run the following command to test access to the s1 swimlane.
  
  The my-trace-id value, s1, is the name of the s1 swimlane configured in Step 1.2.
```
for i in {1..100};  do curl -H'my-trace-id: 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)
```
  The output confirms that requests with the HTTP header my-trace-id: s1 route to the services in the s1 swimlane.
2. Run the following command to test access to the s2 swimlane.
  
  The my-trace-id value, s2, is the name of the s2 swimlane configured in Step 1.2.
```
for i in {1..100};  do curl -H'my-trace-id: s2' http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;
```
  Expected output:
```
mocka(version: v2, ip: 192.168.1.101)-> mockb(version: v1, ip: 192.168.1.100)-> mockc(version: v2, ip: 192.168.1.116)
```
  The output shows that requests with the HTTP header my-trace-id: s2 route to services in the s2 swimlane. When a request targets the mockb service, which does not exist in the s2 swimlane, the fallback mechanism forwards the request to the mockb service in the s1 baseline lane. Subsequent requests to the mockc service correctly route back to the mockc service in the s2 swimlane.
3. Run the following command to test access to the s3 swimlane.
  
  The my-trace-id value, s3, is the name of the s3 swimlane configured in Step 1.2.
```
for i in {1..100};  do curl -H'my-trace-id: s3' 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 shows that requests with the HTTP header my-trace-id: s3 route to the service in the s3 swimlane. When requests target the mocka and mockc services, which do not exist in the s3 swimlane, the fallback mechanism forwards the requests to the mocka and mockc services in the s1 baseline lane.