Microservices Engine:Implement the blue-green deployment, A/B testing, and canary release by using MSE Cloud-native Gateway

Deploy an application

1. Log on to the ACK console. Use the following YAML code to deploy an application with the version of v1.

   For more information about how to deploy an application, see Create a stateless application by using a Deployment.

   apiVersion: v1
   kind: Service
   metadata:
     name: httpbin
   spec:
     ports:
     - port: 8080
       protocol: TCP
     selector:
       app: httpbin
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: httpbin-v1
   spec:
     replicas: 3
     selector:
       matchLabels:
         app: httpbin
         version: v1
     template:
       metadata:
         labels:
           app: httpbin
           version: v1
       spec:
         containers:
         - image: specialyang/spring-cloud-httpbin-k8s:v1
           imagePullPolicy: Always
           name: spring-cloud-httpbin-k8s
           ports:
           - containerPort: 8080

2. Log on to the MSE console. In the MSE console, choose Cloud-native Gateway > Gateways in the left-side navigation pane. Click the gateway that you want to manage. On the gateway details page, choose Service Management > Sources in the left-side navigation pane and click Add Source. In the Add Source panel, select Container Service for Source Type.

   For more information about how to add a service source to a cloud-native gateway, see Add a service source.

   

3. In the left-side navigation pane, choose Service Management > Services. Click Add Service. In the Add Service panel, add the httpbin service that you want to expose to the cloud-native gateway.

   For more information about how to add a service to a cloud-native gateway, see Add a service.

4. Add the v1 version to the httpbin service.

   For more information about how to add a service version to a cloud-native gateway, see Manage service versions.

   Note

   You must filter v1 nodes based on the tag for v1. Currently, only v1 is deployed. Therefore, v1 nodes take up 100% of instance nodes.

   

5. On the Route Settings page, create a route for the service to expose the service to external users. The route of the API operation used to expose the httpbin service is /version. The request is forwarded to the v1 version of the httpbin service.

   For more information about how to configure a route for a cloud-native gateway, see Create a routing rule.

6. Run the following command to send a test request:

   for i in {1..10}; do curl "${GATEWAY_EXTERNAL_IP}/version"; echo "";  done

   Command output:

   version: v1
   version: v1
   version: v1
   version: v1
   version: v1
   version: v1
   version: v1
   version: v1
   version: v1
   version: v1

Perform a blue-green deployment

In a blue-green deployment, the new version of a service must take up the same amount of resources as the current version. After a blue-green deployment is complete, all traffic is switched over to the new version.

1. Deploy the v2 version for the httpbin service by using annotation-based API resources of ACK. The number of replicas is three.

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: httpbin-v2
   spec:
     replicas: 3
     selector:
       matchLabels:
         app: httpbin
         version: v2
     template:
       metadata:
         labels:
           app: httpbin
           version: v2
       spec:
         containers:
         - image: specialyang/spring-cloud-httpbin-k8s:v2
           imagePullPolicy: Always
           name: spring-cloud-httpbin-k8s
           ports:
           - containerPort: 8080

2. Add the v2 version to the httpbin service.

   For more information about how to add a service version to a cloud-native gateway, see Manage service versions.

   Note

   You must filter v2 nodes based on the tag for v2. Currently, the number of v1 nodes is the same as the number of v2 nodes in an instance. Therefore, v1 and v2 nodes each take up 50% of instance nodes.

   

3. Modify the service in the created route to switch traffic from v1 to v2 in the blue-green deployment.

   For more information about how to modify a route for a cloud-native gateway, see Modify a routing rule.

   

4. Run the following command to send a test request:

   for i in {1..10}; do curl "${GATEWAY_EXTERNAL_IP}/version"; echo "";  done

   Command output:

   version: v2
   version: v2
   version: v2
   version: v2
   version: v2
   version: v2
   version: v2
   version: v2
   version: v2
   version: v2

Traffic that accesses API resources by using the /version request path has been switched from v1 to v2.

Perform A/B testing

A/B testing routes traffic to the new version of a service based on the metadata of a user request. A/B testing dynamically routes traffic based on request contents. In this example, the new version can be accessed only by requests whose User-Agent value is Android, and other requests are sent to the original version.

1. The v1 and v2 versions of the httpbin service are still used. In addition, two routing rules need to be created.

   • Requests that match the /version path are routed to the v1 version.

   • Requests that match the /version path and contain Android in the User-Agent header are routed to the v2 version.

   Note

   The version-v2 route must be added with a request header that is used for matching.

2. Run the following command to send a test request that does not contain Android in the User-Agent header:

   curl ${GATEWAY_EXTERNAL_IP}/version

   Command output:

   version: v1

3. Run the following command to send a test request that contains Android in the User-Agent header:

   curl -H "User-Agent: Mozilla/5.0 (Linux; Android 4.0.3)" ${GATEWAY_EXTERNAL_IP}/version

   Command output:

   version: v2

Requests are distributed to different service versions based on operating systems from which the requests are sent.

Perform a canary release

The canary release feature allows a small amount of traffic to be routed to the new version of a service. After the new version is proven to be stable, more traffic is gradually routed to the new version until all traffic is routed to the new version. In this process, the new version is scaled out and the original version is scaled in to maximize the resource utilization.

1. In a canary release, the number of replicas in the new version does not need to be consistent with that in the original version. The only requirement is that resources in the new version must be sufficient to handle canary traffic to the version. In this case, the number of replicas in the new version is set to 1. You can view the node distribution of versions in the Service Version section of the Services page.

   

2. Create a route to forward traffic to the new and original versions of the service based on node weights.

   In the process, you must configure the v1 and v2 versions for the httpbin service and specify the weights based on which traffic is routed. For example, you can select Label Routing for Destination Service and set the weight of the v1 version to 80% and the weight of the v2 version to 20%.

3. Run the following command to send a test request:

   for i in {1..10}; do curl "${GATEWAY_EXTERNAL_IP}/version"; echo "";  done

   Command output:

   version: v1
   version: v1
   version: v1
   version: v1
   version: v1
   version: v2
   version: v1
   version: v2
   version: v1
   version: v1

Two out of ten requests access the v2 version. This traffic distribution ratio is the expected ratio.

Deploy an application

1. Log on to the ACK console. Use the following YAML code to deploy an application with the version of v1.

   For more information about how to deploy an application, see Create a stateless application by using a Deployment.

   Note

   • The ${NACOS_SERVER_ADDRESS} variable in the YAML file must be replaced with the address of your MSE Nacos instance. If your MSE Nacos instance resides in the same VPC as the gateway, you can replace the variable with the internal endpoint of the instance. Otherwise, replace the variable with the public endpoint of the instance.

   • In ACK, data in labels of pods can be considered as node metadata. In Nacos, node metadata is determined by the data carried when a service is registered. In the Spring Cloud framework, you can use the spring.cloud.nacos.discovery.metadata.xxx environment variable to add metadata for a node. In this example, the version is used to distinguish nodes that have different versions. In this case, set spring.cloud.nacos.discovery.metadata.version to v1 for applications.

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: httpbin-v1
   spec:
     replicas: 3
     selector:
       matchLabels:
         app: httpbin
     template:
       metadata:
         labels:
           app: httpbin
       spec:
         containers:
         - image: specialyang/spring-cloud-httpbin-nacos:v1
           imagePullPolicy: Always
           name: spring-cloud-httpbin-nacos
           ports:
           - containerPort: 8080
           env:
           - name: spring.cloud.nacos.discovery.server-addr
             value: ${NACOS_SERVER_ADDRESS} 
           - name: spring.cloud.nacos.discovery.metadata.version
             value: v1

2. Log on to the MSE console. On the Overview page of your gateway, choose Service Management > Sources in the left-side navigation pane. Add an MSE Nacos instance as the service source.

   For more information about how to add a service source to a cloud-native gateway, see Add a service source.

3. On the Overview page of your gateway, choose Service Management > Services in the left-side navigation pane. Import the httpbin service that you want to expose to the cloud-native gateway, and select MSE Nacos as the service source.

   For more information about how to add a service to a cloud-native gateway, see Add a service.

4. Add the v1 version to the httpbin service.

   Note

   You must filter v1 nodes based on the tag for v1. Currently, only v1 is deployed. Therefore, v1 nodes take up 100% of instance nodes.

   

5. On the Route Settings page, create a route for the service to expose the service to external users. The route of the API operation used to expose the httpbin service is /version. The request is forwarded to the v1 version of the httpbin service.

   For more information about how to configure a route for a cloud-native gateway, see Create a routing rule.

6. Run the following command to send a test request:

   for i in {1..10}; do curl "${GATEWAY_EXTERNAL_IP}/version"; echo "";  done

   Command output:

   version: v1
   version: v1
   version: v1
   version: v1
   version: v1
   version: v1
   version: v1
   version: v1
   version: v1
   version: v1

Perform a blue-green deployment

In a blue-green deployment, the new version of a service must take up the same amount of resources as the current version. After a blue-green deployment is complete, the traffic is switched over to the new version.

1. Deploy the new version v2 of the httpbin service.

   Note

   The procedure for registering an application with a Nacos instance is the same as that for registering the service with an ACK cluster. Add the spring.cloud.nacos.discovery.metadata.version=v2 configuration for applications. When an application starts, the application is automatically registered with the Nacos instance and carries custom metadata. The cloud-native gateway can use the metadata to distinguish nodes of different versions.

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: httpbin-v2
   spec:
     replicas: 3
     selector:
       matchLabels:
         app: httpbin
     template:
       metadata:
         labels:
           app: httpbin
       spec:
         containers:
         - image: specialyang/spring-cloud-httpbin-nacos:v2
           imagePullPolicy: Always
           name: spring-cloud-httpbin-nacos
           ports:
           - containerPort: 8080
           env:
           - name: spring.cloud.nacos.discovery.server-addr
             value: ${NACOS_SERVER_ADDRESS}
           - name: spring.cloud.nacos.discovery.metadata.version
             value: v2

2. Add the v2 version to the httpbin service.

   For more information about how to add a service version to a cloud-native gateway, see Manage service versions.

   Note

   You must filter v2 nodes based on the tag for v2. Currently, the number of v1 nodes is the same as the number of v2 nodes in an instance. Therefore, v1 and v2 nodes each take up 50% of instance nodes.

   

3. Modify the destination service in the created route to switch traffic from v1 to v2 in a blue-green deployment.

   For more information about how to modify a route for a cloud-native gateway, see Modify a routing rule.

4. Run the following command to send a test request:

   for i in {1..10}; do curl "${GATEWAY_EXTERNAL_IP}/version"; echo "";  done

   Command output:

   version: v2
   version: v2
   version: v2
   version: v2
   version: v2
   version: v2
   version: v2
   version: v2
   version: v2
   version: v2

Traffic that accesses API resources by using the /version request path has been switched from v1 to v2.

Perform A/B testing

A/B testing routes traffic to the new version of a service based on the metadata of a user request. A/B testing dynamically routes traffic based on request contents. In this example, the new version can be accessed only by requests whose User-Agent value is Android, and other requests are sent to the original version.

1. The v1 and v2 versions of the httpbin service are still used. In addition, two routing rules need to be created.

   • Requests that match the /version path are routed to the v1 version.

   • Requests that match the /version path and contain Android in the User-Agent header are routed to the v2 version.

   Note

   The version-v2 route must be added with a request header that is used for matching.

2. Run the following command to send a test request that does not contain Android in the User-Agent header:

   curl ${GATEWAY_EXTERNAL_IP}/version

   Command output:

   version: v1

3. Run the following command to send a test request that contains Android in the User-Agent header:

   curl -H "User-Agent: Mozilla/5.0 (Linux; Android 4.0.3)" ${GATEWAY_EXTERNAL_IP}/version

   Command output:

   version: v2

Requests are distributed to different service versions based on operating systems from which the requests are sent.