API Gateway:Implement blue-green deployment, A/B testing, and canary release by using Cloud-native API 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. Create an HTTP API. For more information, see Create an HTTP API.

3. Click the target API and click Create Route in the upper-left corner.

4. On the Create Route page, configure the following parameters and click Create Service.

   

5. On the Associated Service page, configure the following parameters and click OK.

   

6. On the Create Route page, select a backend service and click Save and Publish.

   

7. Run the following command to check the result:

   for i in {1..10}; do curl "${Endpoint of the gateway instance}/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, 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 routing rule, see Manage routes.

   

4. Run the following command to check the result:

   for i in {1..10}; do curl "${Endpoint of the gateway instance}/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 ${Endpoint of the gateway instance}/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)" ${Endpoint of the gateway instance}/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 verified, 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 check the result:

   for i in {1..10}; do curl "${Endpoint of the gateway instance}/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.