Implement end-to-end canary release based on lanes - Alibaba Cloud Service Mesh

Service Mesh (ASM) provides two ways of implementing end-to-end canary release. This topic describes how to implement end-to-end canary release based on lanes in an ASM instance.

Prerequisites

An ASM instance of Enterprise Edition or Ultimate Edition is created and the instance is of the latest version. For more information, see Create an ASM instance.
An ACK managed cluster is created. For more information, see Create an ACK managed cluster.
The cluster is added to the ASM instance. For more information, see Add a cluster to an ASM instance.
An ingress gateway is created, and the related HTTP protocol and public IP address are exposed. For more information, see Create an ingress gateway service.
kubectl is used to connect to the ACK cluster and the ASM instance. For more information, see Connect to ACK clusters by using kubectl and Use kubectl on the control plane to access Istio resources.

Feature description

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. Canary release primarily routes request traffic over different workflows. You do not need to reconfigure your microservices for this purpose. Only a few rules are needed to build isolated environments for traffic flow from the gateway to services. Canary release facilitates the release of multiple services or multiple versions of a service at the same time.

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. End-to-end canary release based on lanes

Step 1: Deploy sample services

Enable automatic sidecar injection for the default namespace.
1. Log on to the ASM console.
2. In the left-side navigation pane, choose Service Mesh > Mesh Management.
3. On the Mesh Management page, find the ASM instance that you want to configure. Click the name of the ASM instance or click Manage in the Actions column.
4. On the details page of the ASM instance, choose ASM Instance > Global Namespace in the left-side navigation pane.
5. Find the default namespace and click Enable Automatic Sidecar Injection in the Automatic Sidecar Injection column.
  For more information, see Enable automatic sidecar injection by using multiple methods.

Run the following commands to deploy sample services in the ACK cluster:

kubectl apply -f https://raw.githubusercontent.com/AliyunContainerService/asm-labs/main/fulllink-gray/swimlane/v1/application-v1.yaml
kubectl apply -f https://raw.githubusercontent.com/AliyunContainerService/asm-labs/main/fulllink-gray/swimlane/v2/application-v2.yaml
kubectl apply -f https://raw.githubusercontent.com/AliyunContainerService/asm-labs/main/fulllink-gray/swimlane/v3/application-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, find the ASM instance that you want to configure. Click the name of the ASM instance or click Manage in the Actions column.
On the details page of the ASM instance, choose Traffic Management Center > End-to-end Canary Release in the left-side navigation pane.

On the End-to-end Canary Release page, click Create Lane Group. In the Create Lane Group dialog box, set the parameters and click OK.

The following table describes some parameters that are used to create a lane group.

Parameter	Description
Lane Group Name	The name of the lane group. In this example, the value is set to `test`.
Ingress Gateway	The name of the ingress gateway. In this example, the value is set to ingressgateway.
Lane Service	The services in a lane. Select the ACK cluster and namespace, select mocka, mockb, and mockc in the service list, and then click the icon to add the services to the selected section.

Create s1, s2, and s3 lanes and bind the lanes to v1, v2, and v3.

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

In the Traffic Distribution section of the End-to-end Canary Release page, click Create Lane.

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

Create Lane The following table describes some parameters that are used to create a lane.

Parameter	Description
Lane Name	The name of the lane. The name must be 1 to 63 characters in length and can contain digits, letters, and hyphens (-). In this example, the value is set to `s1`. Note Requests whose headers contain the lane name, such as `'x-asm-prefer-tag: lane name'` are routed to the lane.
Service Tag	The tag of services in the lane. In this example, the value is set to `v1`.
Add Service	Add services to the lane. In this example, mocka(default), mockb(default), and mockc(default) are selected.

After lanes are created, you can view them in the Traffic Distribution section, as shown in the following figure. Lanes

Create a traffic routing rule for each lane.

In the Traffic Distribution section of the End-to-end Canary Release page, find the lane for which you want to create a traffic routing rule, and click Traffic Routing Rule in the Operation column.

In the Add Traffic Routing Rule dialog box, set the parameters and click OK.

This example assumes that the ingress APIs of all the lane services are /mock, and the same traffic routing rule is configured for each lane. The following table describes some parameters that are used to create a traffic routing rule.

Parameter	Description
Ingress Service	The name of the ingress service. In this example, the value is set to mocka.default.svc.cluster.local.
Traffic Routing Rule	The traffic routing rule for the lane. In this example, the Name parameter is set to `r1` and the Domain Name parameter to *.
URI Matching	The URI matching rule. In this example, the Method parameter is set to Exact and the Content parameter to `/mock`.

After traffic routing rules are created, you can view them in the Traffic Distribution section.

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

This topic describes how to verify this feature by using the s1 and s2 lanes. You can use the same method to check the s3 lane.

Run the following command to access services in the s1 lane:
s1 is the name of the lane that you created in Step 2.
```
curl -H 'x-asm-prefer-tag: s1' http://${yourGatewayDomainOrIp}/mock
```
Expected output:
```
-> mocka(version: v1, ip: 10.0.250.213)-> mockb(version: v1, ip: 10.0.250.234)-> mockc(version: v1, ip: 10.0.250.220)
```
The x-asm-prefer-tag: s1 header specifies that traffic flows to services in the s1 lane. The output shows that the feature takes effect.
Run the following command to access services in the s2 lane:
s2 is the name of the lane that you created in Step 2.
```
curl -H 'x-asm-prefer-tag: s2' http://${yourGatewayDomainOrIp}/mock
```
Expected output:
```
-> mocka(version: v2, ip: 10.0.250.229)-> mockb(version: v2, ip: 10.0.250.237)-> mockc(version: v2, ip: 10.0.250.238)
```
The x-asm-prefer-tag: s2 header specifies that traffic flows to services in the s2 lane. The output shows that the feature takes effect.