By Hang Yin
In the previous article Manage End-to-end Traffic Based on Alibaba Cloud Service Mesh (1): Traffic Lanes in Strict Mode, we introduced the scenarios of using the traffic lanes in strict mode based on Alibaba Cloud service mesh (ASM) for end-to-end canary management. This mode has no specific requirements for your application, as you only need to configure traffic lanes to enable end-to-end traffic management. In this article, we will continue with the second mode of traffic lanes: loose mode.
The opposite of traffic lanes in strict mode is traffic lanes in loose mode. In loose mode, you only need to create a baseline lane that includes all services in the relevant call chains. Other lanes do not need to include all services in the call chains. When services in a lane call each other, if the service being called does not exist in the lane, requests are forwarded to the same service in the baseline lane. Once the desired service becomes available in the lane, requests are redirected back to that service within the lane.
When using traffic lanes in loose mode, your application needs to add headers that can be transparently transmitted throughout the corresponding call chains in the requests. These headers should have different values and are known as end-to-end pass-through request headers. Additionally, you need to specify a request routing header. The ASM gateway will forward traffic to different traffic lanes based on the content of the request routing header. This article explains how to implement end-to-end traffic management in ASM using traffic lanes in loose mode.
This article describes the most commonly used scenarios for traffic lanes in loose mode. In this particular scenario, the request header that is transparently transmitted in a call chain is not the request routing header.
In this example, three lanes, s1, s2, and s3, representing three versions of the service call chain, are created for the mocka, mockb, and mockc services, as shown in the figure. The s1 lane is the baseline lane, which includes all three complete services, while the s2 lane only includes the mocka and mockc services, and the s3 lane only includes the mockb service.
• An 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 [1].
• The ACK cluster is added to the ASM instance. For more information, see Add a cluster to an ASM instance [2].
• An ASM gateway named ingressgateway is created. For more information, see Create an ingress gateway [3].
• An Istio gateway named ingressgateway is created in the istio-system namespace. For more information, see Manage Istio gateways [4].
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:
- '*'1. Enable automatic sidecar proxy injection for the default namespace. For more information, see Enable automatic injection [5]. For more information about automatic sidecar proxy injection, see Enable automatic sidecar proxy injection [6].
2. Run the following commands to deploy sample services in the 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.yaml1. Create a lane group.
a) Log on to the ASM console [7]. In the left-side navigation pane, choose Service Mesh > Mesh Management.
b) On the Mesh Management page, click the name of the instance that you want to manage. In the left-side navigation pane, choose Traffic Management Center > Traffic Lane.
c) 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 | For this example, enter test. |
| Entrance gateway | Select ingressgateway. |
| Lane Mode | Select loose mode |
| Request Header Settings | Because the sample application transparently transmits the request header my-request-id in the call chain, the chain pass-through request header is set to my-request-id. The request routing header is used by the gateway to route traffic to different lanes and maintain the context of the lane based on the content of the request header. You can specify this header as x-asm-prefer-tag. |
| 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 is complete, the traffic label is automatically generated. For example, the following traffic label is generated for the Mocka service:
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: mocka2. Create s1, s2, and s3 lanes and bind the lanes to v1, v2, and v3.
a) In the Traffic Rule Definition section of the Traffic Lane page, click Create swimlanes.
b) 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, v2, and v3 respectively for the three lanes. |
| 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.
By default, the first lane you create in a lane group will be set as the baseline lane. You can modify the baseline lane. When traffic is sent to services that do not exist in other lanes, requests are forwarded to the baseline lane through the fallback mechanism.
After the three swimlanes are created, the sample effect is as follows:
Each time you create a lane, the system creates a destination rule. For example, after all swimlanes are created, the following destination rule is automatically created for the s1 service.
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: s2After the three lanes are created, a virtual service, which defines the corresponding traffic routing rules, is generated for each service in the lane group. For example, the following virtual service is automatically created for the mocka 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: s13. Create a traffic routing rule for each lane. The following example describes how to create a traffic routing rule for the s1 lane. Follow these steps to create traffic routing rules for the s2 and s3 lanes.
a) In the Traffic Rule Definition section of the Traffic Lane page, find the lane that you want to manage and click Ingress traffic rules in the Actions column.
b) 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 | 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.
After the three lanes are created, a virtual service, which defines the corresponding traffic routing rules, is generated for each service in the lane group. For example, the following virtual service is generated for lane s2.
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: s11. Obtain the public IP address of the ASM gateway. For more information, see Obtain the IP address of the ASM gateway [8].
2. Run the following command to set environment variables: xxx.xxx.xxx.xxx to the IP address obtained in substep 1.
export ASM_GATEWAY_IP=xxx.xxx.xxx.xxx3. Verify whether the end-to-end canary release feature takes effect.
a) Run the following command to access the 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 Step 2.
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.
b) Run the following command to access the 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 Step 2.
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.
c) 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 Step 2.
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 x-asm-prefer-tag: 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.
In Scenario 1, the request routing headers (my-request-id and x-asm-prefer-tag) differ from the end-to-end pass-through request headers. In this situation, the content of the end-to-end pass-through request headers should vary for each request, ensuring a unique chain ID for each call chain. However, if you specify the end-to-end pass-through request header as the request routing header, the previous limitation for the end-to-end pass-through request header no longer applies. You can route traffic to different lanes based on the content of the end-to-end pass-through request header.
In the example scenario, three lanes (s1, s2, and s3) representing different versions of the service call chain are created for mocka, mockb, and mockc services, as shown in the figure. The s1 lane serves as the baseline lane and includes all three services. The s2 lane includes only the mocka and mockc services, while the s3 lane includes only the mockb service. In this example, both the end-to-end pass-through request header and the request routing header are specified as my-request-id.
• An 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 [1].
• The ACK cluster is added to the ASM instance. For more information, see Add a cluster to an ASM instance [2].
• An ASM gateway named ingressgateway is created. For more information, see Create an ingress gateway [3].
• An Istio gateway named ingressgateway is created in the istio-system namespace. For more information, see Manage Istio gateways [4].
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:
- '*'1. Enable automatic sidecar proxy injection for the default namespace. For more information, see Enable automatic injection [5]. For more information about automatic sidecar proxy injection, see Enable automatic sidecar proxy injection [6].
2. Run the following commands to deploy sample services in the 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.yaml1. Create a lane group.
a) Log on to the ASM console [7]. In the left-side navigation pane, choose Service Mesh > Mesh Management.
b) On the Mesh Management page, click the name of the instance that you want to manage. In the left-side navigation pane, choose Traffic Management Center > Traffic Lane.
c) 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 | For this example, enter test. |
| Entrance gateway | Select ingressgateway. |
| Lane Mode | Select loose mode |
| Request Header Settings | In this example, the end-to-end pass-through request header and the request routing header are all specified as my-request-id. |
| 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. |
2. Create s1, s2, and s3 lanes and bind the lanes to v1, v2, and v3.
a) In the Traffic Rule Definition section of the Traffic Lane page, click Create swimlanes.
b) 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, v2, and v3 respectively for the three lanes. |
| 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.
By default, the first lane you create in a lane group will be set as the baseline lane. You can modify the baseline lane. When traffic is sent to services that do not exist in other lanes, requests are forwarded to the baseline lane through the fallback mechanism.
After the three swimlanes are created, the sample effect is as follows:
Each time you create a lane, the system creates a destination rule. For example, after all swimlanes are created, the following destination rule is automatically created for the s1 service.
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: s2After the three lanes are created, a virtual service, which defines the corresponding traffic routing rules, is generated for each service in the lane group. For example, the following virtual service is automatically created for the mocka 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:
- headers:
my-request-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-request-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-request-id:
exact: s3
route:
- destination:
host: mocka.default.svc.cluster.local
subset: s3
fallback:
target:
host: mocka.default.svc.cluster.local
subset: s13. Create a traffic routing rule for each lane. The following example describes how to create a traffic routing rule for the s1 lane. Follow these steps to create traffic routing rules for the s2 and s3 lanes.
a) In the Traffic Rule Definition section of the Traffic Lane page, find the lane that you want to manage and click Ingress traffic rules in the Actions column.
b) 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 | 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.
After the three lanes are created, a virtual service, which defines the corresponding traffic routing rules, is generated for each service in the lane group. For example, the following virtual service is generated for lane s2.
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-request-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: s11. Obtain the public IP address of the ASM gateway. For more information, see Obtain the IP address of the ASM gateway [8].
2. Run the following command to set environment variables: xxx.xxx.xxx.xxx to the IP address obtained in substep 1.
export ASM_GATEWAY_IP=xxx.xxx.xxx.xxx3. Verify whether the end-to-end canary release feature takes effect.
a) Run the following command to access the services in the s1 lane: In the command, the value of my-request-id is s1, which is the name of the s1 lane that you configured when you created the s1 lane in Step 2.
for i in {1..100}; do curl -H'my-request-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 indicates that traffic specified by the HTTP header my-request-id: s1 flows to the relevant services in the s1 lane. This meets expectations.
b) Run the following command to access the services in the s2 lane: In the command, the value of my-request-id is s2, which is the name of the s2 lane that you configured when you created the s2 lane in Step 2.
for i in {1..100}; do curl -H'my-request-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 indicates that traffic specified by the HTTP header my-request-id: 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.
c) Run the following command to access the service in the s3 lane. In the command, the value of my-request-id is s3, which is the name of the s3 lane that you configured when you created the s3 lane in Step 2.
for i in {1..100}; do curl -H'my-request-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 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.
[1] Create an ASM instance
[2] Add the cluster to the ASM instance
[3] Create an ingress gateway
[4] Manage Istio gateways
[5] Enable automatic injection
[6] Configure automatic sidecar proxy injection
[7] ASM console
[8] Obtain the IP address of the ASM gateway
Manage End-to-end Traffic Based on Alibaba Cloud Service Mesh (ASM): Traffic Lanes in Strict Mode
204 posts | 12 followers
FollowAlibaba Cloud Native - August 7, 2024
Alibaba Cloud Native - January 18, 2024
Alibaba Cloud Community - January 26, 2024
Alibaba Cloud Community - August 9, 2024
Xi Ning Wang(王夕宁) - August 17, 2023
Alibaba Container Service - October 12, 2024
204 posts | 12 followers
Follow
Cloud-Native Applications Management Solution
Accelerate and secure the development, deployment, and management of containerized applications cost-effectively.
Learn More
Function Compute
Alibaba Cloud Function Compute is a fully-managed event-driven compute service. It allows you to focus on writing and uploading code without the need to manage infrastructure such as servers.
Learn More
Alibaba Cloud Service Mesh
Alibaba Cloud Service Mesh (ASM) is a fully managed service mesh platform that is compatible with Istio.
Learn More
Global Traffic Manager
Allows you to access the nearest node based on the Domain Name System (DNS) architecture.
Learn MoreMore Posts by Alibaba Cloud Native