Microservices Engine:Implement an end-to-end canary release based on MSE Ingress gateways

Limits

The end-to-end canary release feature is integrated with the tag-based routing feature. If you use Microservices Governance to implement the end-to-end canary release feature for your applications, we recommend that you do not configure canary release rules and tag-based routing rules for the applications.

Background information

In microservices scenarios in which you have deployed Spring Cloud applications or Dubbo applications and new versions are available for these applications, traffic is randomly routed to the applications regardless of the versions in use. In this case, the traffic that has specific characteristics may not be routed to the desired version of an application. To resolve the issue, you can use the end-to-end canary release feature to isolate specific versions of an application from other versions and route request traffic that matches specific rules to the desired version of the application. You can create lanes that are equivalent to independent runtime environments to isolate application versions and configure routing rules for MSE Ingress gateways to route traffic.

Scenario

This topic provides an example on how to implement an end-to-end canary release from an MSE Ingress gateway to microservice applications in the order placement scenarios of the e-commerce industry. In this example, an application architecture consists of an MSE Ingress gateway and a backend microservices framework (Spring Cloud). The following backend applications are involved in the backend call process: a transaction center (Application A), a commodity center (Application B), and an inventory center (Application C). You can use a client or an HTML page to access these backend applications that are registered with a Nacos instance.

After the customer places an order, traffic flows into the MSE Ingress gateway and is routed to the transaction center (Application A), the commodity center (Application B), and the inventory center (Application C) in sequence. The following call process is used: Customer -> MSE Ingress gateway -> Application A -> Application B -> Application C.

Features of application versions are updated alongside business iterations. Before a new version is officially released for Application A and Application C, you must test the version on both the applications by using a canary release. After the version is proven to be stable, you can release the version for the applications. To release new features of a version, you must release the version for both Application A and Application C. The end-to-end canary release feature is provided based on MSE Ingress gateways and Microservices Governance. You can implement an end-to-end canary release from an MSE Ingress gateway to multiple backend applications. This way, canary traffic that has specific characteristics can always be routed to the canary versions of applications. This helps you test a version on multiple applications by using a canary release. If an application does not have a canary version, traffic is automatically routed to the base version of the application.

Terms

• Lane

  An isolated environment that is defined for applications of the same version. Only traffic that matches specific routing rules can be routed to the tagged applications in a lane. An application can belong to multiple lanes. A lane can contain multiple applications. Applications have a many-to-many relationship with lanes.

• Lane group

  A collection of lanes. A lane group is used to distinguish different teams or different scenarios.

• MSE Ingress gateway

  MSE Ingress gateways allow you to manage ingress traffic based on MSE cloud-native gateways. MSE Ingress gateways are compatible with NGINX Ingress gateways and support more than 50 annotations in NGINX Ingress gateways. MSE Ingress gateways support canary releases of multiple service versions at the same time. MSE Ingress gateways provide flexible service governance capabilities and comprehensive security protection. MSE Ingress gateways are suitable for traffic governance in scenarios in which a large number of cloud-native distributed applications are available.

Preparations

Install the MSE Ingress Controller component

1. Install the MSE Ingress Controller component and grant relevant permissions. For more information, see Grant permissions to MSE Ingress Controller in ACK.

2. Deploy the MSE Ingress Controller component. For more information, see the "Step 2: Configure an IngressClass resource" section in Use MSE Ingresses to access applications in ACK clusters.

Enable Microservices Governance for applications

1. Activate MSE Microservices Governance Professional Edition.

   For more information, see Activate Microservices Governance.

2. Enable Microservices Governance for applications.

   1. Log on to the MSE console.

   2. In the left-side navigation pane, choose Microservices Governance > O&M Center > K8s cluster list. Find the cluster that you want to manage, and click Manage in the Actions column.

   3. On the cluster details page, find the namespace that you want to manage, and click Activate Microservices Governance in the Operation column. In the message that appears, click OK.

Deploy demo applications

1. Log on to the ACK console.

2. In the left-side navigation pane of the ACK console, click Clusters.

3. On the Clusters page, find the cluster that you want to manage and click the name of the cluster or click Details in the Actions column. The details page of the cluster appears.

4. In the left-side navigation pane of the details page, choose Workloads > Deployments.

5. On the Deployments page, select a namespace, and click Create from YAML.

6. Configure the parameters and click Create.

   In this example, a Nacos Server application is deployed to implement service discovery. Applications A, B, and C are deployed. A base version and a canary version are deployed for Applications A and C, and a base version is deployed for Application B.

   Deploy the nacos-server application.

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: nacos-server
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: nacos-server
     template:
       metadata:
         labels:
           app: nacos-server
       spec:
         containers:
         - env:
           - name: MODE
             value: standalone
           image: nacos/nacos-server:v2.2.0
           imagePullPolicy: Always
           name: nacos-server
         dnsPolicy: ClusterFirst
         restartPolicy: Always
   
   # The configuration of the nacos-server service.
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: nacos-server
   spec:
     ports:
     - port: 8848
       protocol: TCP
       targetPort: 8848
     selector:
       app: nacos-server
     type: ClusterIP

   • Deploy Application A.

     • YAML code for the base version

       apiVersion: apps/v1
       kind: Deployment
       metadata:
         name: spring-cloud-a
       spec:
         replicas: 2
         selector:
           matchLabels:
             app: spring-cloud-a
         template:
           metadata:
             labels:
               app: spring-cloud-a
               msePilotAutoEnable: 'on'
               msePilotCreateAppName: spring-cloud-a
           spec:
             containers:
             - env:
               - name: JAVA_HOME
                 value: /usr/lib/jvm/java-1.8-openjdk/jre
               image: registry.cn-shanghai.aliyuncs.com/yizhan/spring-cloud-a:0.1-SNAPSHOT
               imagePullPolicy: Always
               name: spring-cloud-a
               ports:
               - containerPort: 20001
               livenessProbe:
                 tcpSocket:
                   port: 20001
                 initialDelaySeconds: 10
                 periodSeconds: 30

     • YAML code for the canary version

       apiVersion: apps/v1
       kind: Deployment
       metadata:
         name: spring-cloud-a-gray
       spec:
         replicas: 2
         selector:
           matchLabels:
             app: spring-cloud-a-gray
         strategy:
         template:
           metadata:
             labels:
               app: spring-cloud-a-gray
               msePilotAutoEnable: 'on'
               alicloud.service.tag: gray
               msePilotCreateAppName: spring-cloud-a
           spec:
             containers:
             - env:
               - name: JAVA_HOME
                 value: /usr/lib/jvm/java-1.8-openjdk/jre
               image: registry.cn-shanghai.aliyuncs.com/yizhan/spring-cloud-a:0.1-SNAPSHOT
               imagePullPolicy: Always
               name: spring-cloud-a-gray
               ports:
               - containerPort: 20001
               livenessProbe:
                 tcpSocket:
                   port: 20001
                 initialDelaySeconds: 10
                 periodSeconds: 30

   • Deploy Application B.

     YAML code for the base version

     apiVersion: apps/v1
     kind: Deployment
     metadata:
       name: spring-cloud-b
     spec:
       replicas: 2
       selector:
         matchLabels:
           app: spring-cloud-b
       strategy:
       template:
         metadata:
           labels:
             app: spring-cloud-b
             msePilotAutoEnable: 'on'
             msePilotCreateAppName: spring-cloud-b
         spec:
           containers:
           - env:
             - name: JAVA_HOME
               value: /usr/lib/jvm/java-1.8-openjdk/jre
             image: registry.cn-shanghai.aliyuncs.com/yizhan/spring-cloud-b:0.1-SNAPSHOT
             imagePullPolicy: Always
             name: spring-cloud-b
             ports:
             - containerPort: 8080
             livenessProbe:
               tcpSocket:
                 port: 20002
               initialDelaySeconds: 10
               periodSeconds: 30

   • Deploy Application C.

     • YAML code for the base version

       apiVersion: apps/v1
       kind: Deployment
       metadata:
         name: spring-cloud-c
       spec:
         replicas: 2
         selector:
           matchLabels:
             app: spring-cloud-c
         template:
           metadata:
             labels:
               app: spring-cloud-c
               msePilotAutoEnable: 'on'
               msePilotCreateAppName: spring-cloud-c
           spec:
             containers:
             - env:
               - name: JAVA_HOME
                 value: /usr/lib/jvm/java-1.8-openjdk/jre
               image: registry.cn-shanghai.aliyuncs.com/yizhan/spring-cloud-c:0.1-SNAPSHOT
               imagePullPolicy: Always
               name: spring-cloud-c
               ports:
               - containerPort: 8080
               livenessProbe:
                 tcpSocket:
                   port: 20003
                 initialDelaySeconds: 10
                 periodSeconds: 30

     • YAML code for the canary version

       apiVersion: apps/v1
       kind: Deployment
       metadata:
         name: spring-cloud-c-gray
       spec:
         replicas: 2
         selector:
           matchLabels:
             app: spring-cloud-c-gray
         template:
           metadata:
             labels:
               app: spring-cloud-c-gray
               msePilotAutoEnable: 'on'
               alicloud.service.tag: gray
               msePilotCreateAppName: spring-cloud-c
           spec:
             containers:
             - env:
               - name: JAVA_HOME
                 value: /usr/lib/jvm/java-1.8-openjdk/jre
               image: registry.cn-shanghai.aliyuncs.com/yizhan/spring-cloud-c:0.1-SNAPSHOT
               imagePullPolicy: IfNotPresent
               name: spring-cloud-c-gray
               ports:
               - containerPort: 8080
               livenessProbe:
                 tcpSocket:
                   port: 20003
                 initialDelaySeconds: 10
                 periodSeconds: 30

7. Configure two Kubernetes services for Application A that is an ingress application.

   1. Log on to the ACK console.

   2. In the left-side navigation pane of the details page, choose Network > Services

   3. On the Services page, select a namespace and click Create Resources in YAML. On the Create page, configure the parameters, and click Create.

      • YAML code for the spring-cloud-a-base service that is deployed for the base version of Application A

        apiVersion: v1
        kind: Service
        metadata:
          name: spring-cloud-a-base
        spec:
          ports:
            - name: http
              port: 20001
              protocol: TCP
              targetPort: 20001
          selector:
            app: spring-cloud-a

      • YAML code for the spring-cloud-a-gray service that is deployed for the canary version of Application A

        apiVersion: v1
        kind: Service
        metadata:
          name: spring-cloud-a-gray
        spec:
          ports:
            - name: http
              port: 20001
              protocol: TCP
              targetPort: 20001
          selector:
            app: spring-cloud-a-gray

Step 1: Create a lane group

1. Log on to the MSE console, and select a region in the top navigation bar.

2. In the left-side navigation pane, choose Microservices Governance > Full link grayscale.

3. On the Full link grayscale page, click Create Lane Group and Lane. If a lane group is available in the microservice namespace that you select, click Create Lane Group.

4. In the Create Lane Group panel, configure the parameters and click OK.

   Parameter	Description
   Lane Group Name	Enter a name of the lane group.
   Ingress Type	Select ingress.
   Lane Group Application	Select all related services involved in your ingress application or Ingress gateway.

   After the lane group is created, check whether the ingress application and other involved applications are valid. You can view the lane group that you created in the Lane Groups and Involved Applications section on the Full link grayscale page. To change the lane group information, click the icon on the right and modify the information.

Step 2: Create a lane

1. On the Full link grayscale page, select the region in which the lane group resides in the top navigation bar, and click Create First Split Lane in the lower part.

   If a lane is available in the microservice namespace that you select, click Create Lane.

   Important

   If the end-to-end canary release feature is enabled for applications, we recommended that you do not use the canary release and tag-based routing features for these applications.

2. In the Create Lane panel, configure the parameters and click OK.

   Important

   If your gateway is an Ingress gateway, you must configure Ingress routing rules in the ACK console. For more information, see Create an NGINX Ingress.

   Parameter	Description
   Lane Name	Enter a name of the lane.
   Lane Tag	Configuration method: In the ACK console, add alicloud.service.tag:{tag} to spec.template.metadata.labels in the YAML file of the application. Add a tag: For example, if you want to add the gray tag for Application B, add the following configuration items to spec.template.metadata.labels: msePilotCreateAppName:${AppName} alicloud.service.tag:gray
   Add Application	After the application tag is configured, the tag is displayed in the drop-down list of the Add Application section. Then, select the configured tag from the drop-down list. The tagged applications are automatically added.

   After you create a lane, view or configure the lane information in the Traffic Distribution section on the Full link grayscale page.

   • Click the icon to view the traffic percentage of the lane.

   • Click the icon to configure the status of the lane application in the Actions column.

     • Enable a lane: Click Enable. Traffic is routed based on the configurations of the lane. Traffic is preferentially routed to the application versions that have the lane tag. If the tagged application versions do not exist, traffic is routed to the untagged application versions.

     • Disable a lane: Click Disable. Traffic of an application in the lane is subsequently routed to the untagged application versions.

     • Edit information about a lane: Click Edit.

     • Delete a lane: Click Delete.

Step 3: Configure Ingress rules for base versions

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: spring-cloud-a
  namespace: default
spec:
  ingressClassName: mse
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: spring-cloud-a-base
                port:
                  number: 20001
            path: /
            pathType: Prefix

curl -H "Host:www.example.com" http://106.14.XX.XX/a

Step 4: Configure Ingress routing rules for the canary versions

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary: 'true'
    nginx.ingress.kubernetes.io/canary-by-header: x-user-id
    nginx.ingress.kubernetes.io/canary-by-header-value: '100'
    mse.ingress.kubernetes.io/request-header-control-update: x-mse-tag gray
  name: spring-cloud-a-gray
  namespace: default
spec:
  ingressClassName: mse
  rules:
    - host: example.com
      http:
        paths:
          - backend:
              service:
                name: spring-cloud-a-gray
                port:
                  number: 20001
            path: /
            pathType: Prefix

curl -H "host: example.com" -H "x-user-id: 100" 47.101.XX.XX/a

View the traffic monitoring charts of applications in the MSE console

• View the monitoring chart of a single application.

  1. On the Full link grayscale page, click the tab of the lane group whose monitoring information you want to view.

  2. In the Applications Related to Lane Group section, click the name of the application whose monitoring chart you want to view. The queries per second (QPS) monitoring chart is displayed in the QPS monitoring diagram (general) section on the right.

• View the monitoring charts of all applications in the lane group.

  1. On the Full link grayscale page, click the tab of the lane group whose monitoring information you want to view.

  2. Click View Traffic Monitoring Data of All Applications (Traffic Escape Observation) on the right of the QPS monitoring diagram (general) section to view the traffic monitoring charts of all applications in the lane.