All Products
Search
Document Center

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

Last Updated:Mar 18, 2024

Microservices Engine (MSE) allows you to implement an end-to-end canary release based on MSE Ingress gateways. This way, you can implement end-to-end traffic throttling without the need to modify your business code. This topic describes how to use MSE Ingress gateways to implement an end-to-end canary release.

Prerequisites

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.

Item

Requirement

Description

Spring Cloud version

Spring Cloud Edgware and later

None.

Dubbo version

V2.5.3 to V2.7.8

The feature support of Dubbo 3.0 or later versions are in a canary release. To use the end-to-end canary release feature, submit a ticket.

Client type

  • Resttemplate

  • Spring Cloud OpenFeign

None.

JDK version

JDK 1.6, 1.7, 1.8, 1.11, and 1.17

None.

Load balancer type

  • Ribbon 2.0.x and later

  • LoadBalancer 3.0.x and later

None.

Spring Cloud Gateway version

Spring Cloud Gateway 2.1.0.RELEASE and later

None.

Spring Cloud Zuul version

1.3.x

None.

Registry type

  • Nacos

  • ZooKeeper

The microservices governance capability is irrelevant to registries. Therefore, both MSE instances and self-managed registries are supported.

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.

    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

If the service domain name is example.com and you want to route traffic of requests to access example.com to only base versions (online versions), you can use the following code to configure Ingress rules for the 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

Use the curl command to access example.com and route traffic to the base versions.

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

The following result is returned:

A[172.18.XX.XX] -> B[172.18.XX.XX] -> C[172.18.XX.XX]%

Step 4: Configure Ingress routing rules for the canary versions

You use a header-based routing rule to distinguish base traffic and canary traffic. You want to route requests with the HTTP header x-user-id: 100 to canary versions for access to example.com. In this example, requests are preferentially routed to the canary version of each application. If an application has no canary version, requests are routed to the base version of the application. The following code is used to configure an Ingress routing rule 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

The preceding code uses annotations to implement the canary release, header configuration, and header control capabilities. For more information about how to use annotations, see Advanced usage of MSE Ingress.

Run the curl command to access example.com and route requests with the HTTP header x-user-id: 100 to the canary versions.

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

The following result shows that canary traffic is preferentially routed to the canary versions of Applications A and C. For Application B, traffic is routed to the base version because no canary version is available for the application.

Agray[10.1.XX.XX] -> B[10.1.XX.XX] -> Cgray[10.1.XX.XX]%

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.