Overview

Background

When switching between old and new services, you may be challenged in ensuring the system service continuity. If a new service version is directly released to all users at a time, it can be risky because once an online accident or bug occurs, the impact on users is great. It could take a long time to fix the issue. Sometimes, the version has to be rolled back, which severely affects user experience.

Solution

Several release policies are developed for service upgrades, including grayscale releases, blue-green deployment, A/B testing, rolling upgrades, and batch suspension of releases. Traffic loss or service unavailability caused by releases can be avoided as much as possible.

This section describes the principles and practices of grayscale releases and blue-green deployment.

• Grayscale releases, also called canary releases, are a smooth iteration mode for version upgrades. During the upgrades, some users use the new version, while other users continue to use the old version. After the new version is stable and ready, it gradually takes over all the live traffic. In this way, service risks brought by the release of the new version can be minimized, the impact of faults can be reduced, and quick rollbacks are supported.

  The figure below shows the general process of a grayscale release. First, divide 20% of all service traffic to the new version. If the service version runs normally, gradually increase the traffic proportion and continue to test the performance of the new version. If the new version is stable, switch all traffic to it and bring the old version offline.

  

  If an exception occurs in the new version when 20% of the traffic goes to it, you can quickly switch back to the old version.

  

• Blue-green deployment provides a zero-downtime, predictable manner for releasing applications to reduce service interruption during the release. A new version is deployed while the old version is retained. The two versions are online concurrently. The new and old versions work in hot backup mode. The route weight is switched (0 or 100) to enable different versions to go online or offline. If a problem occurs, the version can be quickly rolled back.

  

Realizing Grayscale Release or Blue-Green Deployment

Kubernetes-native features can be used to implement simple grayscale release or blue-green deployment. For example, you can change the value of the label that determines the service version in the selector of a Service to change the pod backing the Service. In this way, the service can be directly switched from one version to another. If you have complex grayscale release or blue-green deployment requirements, you can deploy service meshes and open-source tools, such as Nginx ingresses and Traefik, to the cluster. You can obtain detailed instructions in the following sections:

• Using Services to Implement Simple Grayscale Release and Blue-Green Deployment
• Using an Nginx Ingress for Grayscale Release and Blue-Green Deployment

Both Services and Nginx ingresses use open-source Kubernetes capabilities for grayscale release and blue-green deployment. In this process, CCE allows you to easily perform the following operations:

• All resources can be created, viewed, and modified on the console, which is more intuitive than the kubectl command line tool.
• LoadBalancer Services are supported by ELB. When creating a Service, you can use an existing ELB load balancer or create a new one.
• The NGINX Ingress Controller add-on can be installed in just a few clicks, and ELB load balancers can be created and interconnected during the installation.