All Products
Search
Document Center

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

Last Updated:Oct 24, 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.

For more information about the Java versions and frameworks supported by end-to-end canary release, see Java frameworks supported by Microservices Governance.

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 environment of the application.

全链路灰度场景

Terms

  • Lane

    An isolated environment that is defined for applications of the same version. Only traffic that matches specific traffic control rules can be routed to the applications that are marked 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 between different teams or 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

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.

    Show YAML code

    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: registry.cn-hangzhou.aliyuncs.com/mse-governance-demo/nacos-server:v2.1.2
            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

        Show the 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-hangzhou.aliyuncs.com/mse-governance-demo/spring-cloud-a:3.0.1
                imagePullPolicy: Always
                name: spring-cloud-a
                ports:
                - containerPort: 20001
                livenessProbe:
                  tcpSocket:
                    port: 20001
                  initialDelaySeconds: 10
                  periodSeconds: 30
      • YAML code for the canary version

        Show the 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-hangzhou.aliyuncs.com/mse-governance-demo/spring-cloud-a:3.0.1
                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

        Show the 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-hangzhou.aliyuncs.com/mse-governance-demo/spring-cloud-b:3.0.1
                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

        Show the 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-hangzhou.aliyuncs.com/mse-governance-demo/spring-cloud-c:3.0.1
                imagePullPolicy: Always
                name: spring-cloud-c
                ports:
                - containerPort: 8080
                livenessProbe:
                  tcpSocket:
                    port: 20003
                  initialDelaySeconds: 10
                  periodSeconds: 30
      • YAML code for the canary version

        Show the 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-hangzhou.aliyuncs.com/mse-governance-demo/spring-cloud-c:3.0.1
                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, which 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

        Show YAML code

        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

        Show YAML code

        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/Self-managed Gateway.

    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

    Add Node 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: Add the following key-value pairs to spec.template.metadata.labels.

      • msePilotCreateAppName:${AppName}

      • alicloud.service.tag:{tag}

    Lane Name

    Enter a name for the lane.

    Lane Tag

    After the node tag is configured, the tag is displayed in the Lane Tag drop-down list. If you select the tag that you configured from the drop-down list, the tag is automatically added to the applications in the lane.

    After you create a lane, you can 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.

Show YAML code

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: example.com" http://47.98.xxx.xx/a

The following result is returned:

A[192.168.0.98][config=base] -> B[192.168.0.157] -> C[192.168.0.161]

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.

Show YAML code

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" http://47.98.xxx.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[192.168.0.128][config=base] -> B[192.168.0.152] -> Cgray[192.168.0.151]

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 Lane Groups and Involved Applications section, click the name of the application whose monitoring information you want to view. The queries per second (QPS) data is displayed in the QPS data section on the right of the page.

  • 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. On the right side of the Application QPS Monitoring section, click View Traffic Details to view the traffic monitoring charts of all applications in the lane.