Kubernetes service release methods (blue-green release, grayscale release, and rolling release)

---

1. Three commonly used project release methods

The biggest challenge facing application upgrades is switching between old and new services, bringing the software from the final stage of testing to the production environment, and at the same time ensuring that the system provides uninterrupted services. The three most common release methods are: blue-green release , grayscale release , and rolling release .

The ultimate goal of the three release methods is to reduce or avoid the impact on customer use when the application is updated, and avoid traffic loss or service unavailability caused by the release as much as possible.

1.1 Blue-green release

First, divide all application service clusters into blue and green groups. First, remove the clusters of the green group from load balancing, and the blue group will continue to provide services to users. At this time, the removed green group performs service upgrades, and after the upgrade is completed, the green group is reconnected to the load balancer to provide services for users.
Then remove the blue group, upgrade the service, and connect it to the load-balanced cluster after the upgrade is complete. At this point, the entire project cluster has to be upgraded, which we call blue-green release.

The project is logically divided into group AB. In the project system, group A is first removed from the load balancing and the new version is deployed. Group B still continues to provide services.

When group A is upgraded, the load balancer reconnects to group A, and removes group B from the load list to deploy the new version. Group A resumes service.

Finally, the upgrade of group B is also completed, and the load balancing is reconnected to group B. At this time, the version of group AB has been upgraded and provides services to the outside world.

Features:

• If there is a problem, the scope of influence is relatively large;
• The release strategy is simple;
• The user has no perception, smooth transition;
• Upgrade/rollback is fast.

shortcoming:

• It is necessary to prepare servers with more than twice the resources used by normal business to prevent a single group from being unable to carry business bursts during the upgrade period;
• A certain resource cost is wasted in a short period of time;
• The infrastructure remains unchanged, increasing the stability of the upgrade.

Blue-green releases were relatively expensive in the early days of physical servers. Due to the popularity of cloud computing, the cost has also been greatly reduced.

1.2 Grayscale Release (Canary Release)

Grayscale release is also called canary release. Grayscale refers to a release method that can smoothly transition between black and white (why is it called Canary release? Check if there is any poisonous gas below, the miners will first put a canary in to see if there is any poisonous gas, to see if the canary can survive.)

This process is similar to the experience server in the game. First, some users will be allowed to test the use. If there are no problems, it will be gradually promoted to completely replace the old version.

Grayscale release only upgrades some services, that is, let some users continue to use the old version, and some users start using the new version. If users have no complaints about the new version, then gradually expand the scope and migrate all users to the new version.

features

• Ensure the stability of the overall system. Problems can be found and adjusted at the initial grayscale, and the scope of influence is controllable;
• The new function gradually evaluates the performance, stability and health status. If there is a problem, the scope of impact is small and the relative user experience is relatively small;
• The user is imperceptible and the transition is smooth.

shortcoming

• High automation requirements

deployment process

• Remove the grayscale server from the LB, and then join the LB after the upgrade is successful;
• A small amount of user traffic to the new version;
• If the grayscale server test is successful, upgrade the remaining servers.

Grayscale release is a process of gradually switching from one version to another by switching the routing weights between online coexisting versions.

1.3 Rolling release

Rolling release refers to upgrading only one or more services each time. After the upgrade is completed, join the production environment and continue to perform this process until all the old versions in the cluster are upgraded to the new version.

• Red: Instances being updated
• Blue: Instances that have been updated and joined the cluster
• Green: running instance

features

• The user has no perception, smooth transition;
• save resources.

shortcoming

• The deployment time is slow, depending on the update time of each stage;
• The release strategy is more complicated;
• It is impossible to determine the OK environment, and it is not easy to roll back.

deployment process

• Upgrade one copy first, mainly for deployment verification;
• Every time the copy is upgraded, it is automatically removed from the LB, and it is automatically added to the cluster after the upgrade is successful;
• There needs to be an automatic update strategy in advance, divided into several times, each time the number/percentage can be configured;
• Rollback is the reverse process of release. First remove the new version from LB, and then upgrade the old version. This process usually takes a long time;
• Automation requirements are high.

2. Canary mode upgrade and release experiment

Select one of the node nodes to pull the image, one version nginx:1.14, one version nginx:1.16

export the image and copy it to another node node

Import the copied image to

create a pod on the master node



and use the canary method to upgrade and release

Open another master process


and go back to the previous master process.






Now a quarter of the traffic is updated to nginx: version 1.16, and all updates will be done without any problems.

View update status in another process

3. Summary

To sum up, all three methods can achieve smooth upgrades. During the upgrade process, the service still maintains service continuity, and the upgrade is insensitive to the outside world. Which deployment method is the most suitable for production? It depends on which approach is best for your business and technical needs. If your operation and maintenance automation capacity reserve is not enough, the simpler the better, it is recommended to release in blue and green. If the business is highly dependent on users, it is recommended to release in grayscale. If it is a K8S platform, rolling update is a ready-made solution, and it is recommended to use it directly.

Blue-green release: The two environments are upgraded alternately, and the old version is kept for a certain period of time for easy rollback.

Grayscale release: The old version is upgraded according to the proportion, for example, 80% of the user access is the old version, and 20% of the user access is the new version.

Rolling release: Stop the old version instances in batches and start the new version instances.