Full-link traffic management based on Alibaba Cloud service grid traffic lanes (1): Strict mode traffic lanes

12.23 Yuan Chuanghui·Shanghai Station, let’s talk about LLM infrastructure

Author: Yin Hang

Overview

Grayscale release is a common method of releasing new versions of application services. Its characteristic is that it can switch traffic between the stable version and the grayscale version of the service at all times to help us upgrade services in a more reliable way. In the process of switching the traffic proportion, we can gradually verify the functional features, reliability and other characteristics of the new version of the service. Once the new version of the service does not meet the needs, we can always switch the traffic back to the old version. Therefore, grayscale release is also a kind of A widely used release solution in the field of software engineering.

Currently, the non-intrusive grayscale release of service mesh is already a very mature feature: we can deploy multiple versions of services at the same time, use DestinationRule to formulate workload version definitions, and use VirtualService's ability to split traffic proportions. Different proportions of service traffic are sent to different versions of the workload, until all traffic is sent directly to the new version of the service.

However, in the context of the widespread adoption of cloud native applications, applications often no longer exist in the form of single services, but are decomposed into a series of cloud native services deployed in Kubernetes clusters. There are call links and jointly provide external services.

When there are call links between services, the grayscale release of services is often not limited to a single service, but requires environmental isolation and traffic control of the entire request link of the service, that is, ensuring that grayscale traffic is only sent to Call the grayscale version of the service in the link to achieve an isolation environment in which the calling links are isolated from each other. The traffic management requirements for the entire call link bring new challenges to the non-intrusive traffic management solution of the service mesh:

Traffic rules are highly complex

The VirtualService and DestinationRule rules based on the Istio community need to be customized individually for each service. In the scenario of full-link traffic management, the probability of configuration errors and the maintenance cost of service traffic will increase.
Low flexibility in traffic management

For different full-link traffic management needs, it is difficult to achieve all needs by simply adjusting traffic rules (for example: for a gray link, only release new versions of some services in the link).

Service grid ASM supports isolating relevant versions of applications (or other characteristics) into an independent running environment (i.e. swim lane), and then by setting swim lane rules, the request traffic that satisfies the rules is routed to the application of the target version (or other characteristics) superior. ASM flow lanes have the following characteristics:

Simple configuration

By using the ASM traffic lane function, you only need to formulate a small number of governance rules to build multiple traffic isolation environments from the gateway to the entire back-end service, effectively ensuring the smooth and safe release of multiple services and the parallel development of multiple versions of services, further promoting Rapid business development.
Support full-link traffic management requirements in different dimensions

ASM traffic lanes support strict mode and relaxed mode. Each of the two modes has its own advantages, restrictions, and adaptation usage scenarios, adapting to more diverse traffic management needs.

Strict mode and loose mode of traffic swimlane

1. Strict mode traffic lanes

In strict mode, each traffic lane contains all services on the calling link. This mode has no requirements for your application other than configuring traffic swimlanes. As shown below:

2. Traffic lanes in relaxed mode

In relaxed mode, you just need to make sure to create one swimlane that contains all services in the call chain: the baseline swimlane. Other swim lanes may not include all services on the call link. When services in a swim lane call each other, if the target service does not exist in the current swim lane, the request will be forwarded to the same service in the baseline swim lane, and the request will be re-forwarded back to the current swim lane if the target service exists in the current swim lane. lane. When using relaxed mode traffic swimlanes, your application must include a request header that can be transparently transmitted in the entire call link (Link Transparent Request Header), and additionally use a diversion request header to redirect traffic based on the request header content. Traffic is routed to different traffic lanes. As shown below:

The following article mainly demonstrates the application of strict mode swim lanes in service grid ASM.

Demonstration: Using strict mode traffic lanes to achieve full-link grayscale management

In the example scenario of this article, the three services mocka, mockb, and mockc shown in the figure above will be used to create three swim lanes representing three versions of the service call chain: s1, s2, and s3.

1. Prerequisites

An ASM Enterprise or Ultimate instance has been created and is version 1.18.2.111 and above. For specific operations, see Creating an ASM Instance [ 1] .
Added ACK cluster to ASM instance. For specific operations, see Adding a Cluster to an ASM Instance [ 2] .
An ASM gateway named ingressgateway has been created. For specific operations, see Creating an Ingress Gateway Service [ 3] .
A gateway rule named ingressgateway with namespace istio-system has been created. For specific operations, see Managing Gateway Rules [ 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:
        - '*'

2. Deploy the sample service

First deploy the application service in the example in the ACK cluster to realize the full-link grayscale scenario. Enable automatic injection of the Sidecar grid proxy for the default namespace (for specific operations, see Enable automatic injection[ 5] ), then execute the following command in the ACK cluster to deploy the sample service.

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

3. Create lane groups and corresponding lanes

In the example, we separate the v1, v2, and v3 versions of the mocka->mockb->mockc service call link into three lanes: s1, s2, and s3. The set of three lanes is called a lane group. In service mesh ASM, the creation of swim lane groups and swim lanes can be completed through simple configuration.

Log in to the ASM console[ 6] , select Service Grid in the left navigation bar > Grid management.
On the grid management page, click the target instance name, and then select Traffic Management Center > Traffic Swimlane in the left navigation bar.
On the Traffic Lanes page, click Create Lane Group, configure the relevant information in the Create Lane Group panel, and then click OK.

Configuration items	illustrate
lane group name	This example is configured as test.
Ingress gateway	Select ingressgateway.
swim lane mode	Choose strict mode
lane service	Select the target Kubernetes cluster and default namespace, select the mocka, mockb, and mockc services in the list below, click the icon, and add the target service to the selected area.

Next, create s1, s2, and s3 swim lanes in the swim lane group, corresponding to the v1, v2, and v3 versions of the service call link respectively.

In the traffic rule definition area of the Traffic Swimlane page, click Create Swimlane.
In the Create Swimlane dialog box, configure the relevant information and click OK.

After the three swim lanes are created, the sample effect is as follows:

Each time a swim lane is created, the traffic lane will automatically create a DestinationRule corresponding to the swim lane. For example, after all swim lanes are created, the following destination rule DestinationRule will be automatically created for the mocka service.

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

After the three swim lanes are created, the virtual service VirtualService corresponding to the swim lane rules will be generated for each service in the swim lane group. For example, the following virtual service VirtualService 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:
        - 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

Finally, create traffic diversion rules corresponding to each swim lane. Through different traffic diversion rules, ASM gateway can route requests with different characteristics to different swim lane isolation environments to achieve complete isolation between service call links in the swim lane. The following is an example of creating a traffic diversion rule for the s1 lane. Please follow the steps below to create a traffic diversion rule for the s2 and s3 lanes.

In the traffic rule definition area of the traffic lane page, click the traffic diversion rule under the action column on the right side of the target lane.
In the Add Traffic Diversion Rule dialog box, configure the relevant information, and then click OK. This article takes the entry API corresponding to the swim lane service as /mock as an example, and configures the same traffic diversion rules for each swim lane.

Configuration items	illustrate
Entrance service	Select mocka.default.svc.cluster.local.
Drainage rules	The configuration name is r1 and the domain name is *.
Match the requested URI	Configure the matching mode to exact and the matching content to /mock.
Add Header matching rules	Click Add Header Matching Rule. In the added Header Matching Rule, fill in the name as x-asm-prefer-tag, the matching mode as exact, and the matching content as s1.

After the traffic diversion rules for the three lanes are successfully created, the sample effect is as follows:

After successful creation, the traffic diversion rules for each swim lane will be automatically generated, that is, the virtual service VirtualService. For example, the following virtual service VirtualService will be generated for swim lane s1:


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

4. Verify whether the full-link grayscale function is effective

Through the above rule configuration, ASM traffic lanes have automatically created traffic rules to maintain mutual isolation between different calling links. You can verify whether the full-link grayscale implemented through traffic lanes is effective through simple access.

1) Obtain the IP address of the ASM gateway (refer to Obtaining the ASM gateway address[ 7] ) .

2) Execute the following command to set environment variables. xxx.xxx.xxx.xxx is the IP obtained in the previous step.

export ASM_GATEWAY_IP=xxx.xxx.xxx.xxx

3) Verify whether the full grayscale link function is effective.

Execute the following command to view the access effect of the s1 swim lane. The value s1 corresponding to x-asm-prefer-tag is the lane name configured when creating the s1 lane in step 2.

for i in {1..100}; do curl   -H 'x-asm-prefer-tag: 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)

From the expected output, traffic declared by setting the HTTP header x-asm-prefer-tag: s1 flows to the relevant service under the s1 swim lane, as expected.

Execute the following command to view the access effect of the s2 swim lane. The value s2 corresponding to x-asm-prefer-tag is the lane name configured when creating the s2 lane in 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)

From the expected output, traffic declared by setting the HTTP header x-asm-prefer-tag: s2 flows to the relevant service under the s2 swim lane, as expected.

Execute the following command to check the access effect of s3 swim lane. The value s3 corresponding to x-asm-prefer-tag is the lane name configured when creating the s3 lane in 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)

From the expected output, traffic declared by setting the HTTP header x-asm-prefer-tag: s3 flows to the relevant service under the s3 swim lane, as expected.

Summarize

This article briefly discusses the challenges and limitations in the full-link traffic management scenario when using service grids to manage cloud native application traffic; and introduces the traffic lane capabilities in service grid ASM in full-link traffic management of service grids. The following advantages and features. Next, the strict mode of ASM traffic lanes is demonstrated and explained in detail. Next, we will provide a further in-depth introduction to the ASM traffic lanes in relaxed mode.

[2] Add cluster to ASM instance https://help.aliyun.com/document_detail/148231.html#task-2372122

[3] Create entry gateway service https://help.aliyun.com/document_detail/150510.html#task-2372970

[4] Management gateway rules https://help.aliyun.com/document_detail/150504.html

[5] Enable automatic Sidecar injection https://help.aliyun.com/document_detail/186136.html#task-1962690

[6] ASM 控制台 https://servicemesh.console.aliyun.com/

[7] Get ASM gateway address https://help.aliyun.com/document_detail/444079.html#section-ida-zt6-md7

Clickhere to learn more about service mesh ASM products