Today, I will continue to introduce the relevant knowledge of Linux operation and maintenance. The main content of this article is the canary release.
1. Definition of Canary Release
Canary release, that is, grayscale release, is a way of releasing Pods. The canary release adopts the method of adding and then deleting to ensure that the total number of Pods is not lower than the expected value. And after updating some Pods, suspend the update, and update other versions of Pods after confirming that the new Pod version is running normally.
The Deployment controller supports Pod updates in a canary manner. Today, we come to the actual combat of the canary release.
2. Canary release actual combat
First, let's create a Deployment controller, as shown below:
Next, let's set the parameters of the canary release and execute the command:
kubectl patch deployment deployment -p '{"spec":{"strategy":{"rollingUpdate":{"maxSurge":1,"maxUnavailable":0}}}}'
The execution result is as follows:
In the above command, we attach two parameters, maxSurge and maxUnavailable to the Deployment control, set maxSurge to 1, and set maxUnavailable to 0, so that the number of Pods can be exactly equal to the number we expect, or more One more quantity.
Next, after the parameters are set, we can start to update, execute the command:
kubectl set image deployment deployment myapp=ikubernetes/myapp:v2 && kubectl rollout pause deployment deployment
In this command, the previous command can make the Deployment controller update to the v2 version of myapp. After the previous command is successfully executed, the following command will be executed immediately, that is, the update of the Deployment controller will be suspended. The execution results of these two commands are as follows:
After the above commands are executed, let's check the current Pod situation, as shown below:
As can be seen from the above figure, the number of Pods we expect is 3, and the current number of Pods is 4, we check the specific information of the current Pod and execute the command:
kubectl get pods -o custom-columns=Name:metadata.name,Image:spec.containers[0].image
The command execution result is as follows:
As can be seen from the above figure, in the current state, there are a total of four Pods under the Deployment controller, one of which is the v2 version, and the other three Pods are the v1 version.
Next, we check the update status of the current Deployment and execute the command:
kubectl rollout status deployment deployment
The execution results are as follows:
As can be seen from the above figure, the update of the current Deployment controller has been completed and is in a suspended state. At this point, if it is in a production environment, we are in a state where the new version and the old version coexist, and we can use this to check the operation of the new version of the Pod. If there is no problem with the new version of the Pod, then we can proceed with the update and execute the command:
kubectl rollout resume deployment deployment
The execution result is as follows:
At this time, let's check the update status of the deployment controller, and the result is as follows:
As can be seen from the above figure, we have successfully updated the Pod under the deployment controller. At this time, let's check the Pod again, and the result is as follows :
From the picture above, we can see that all our Pods are in v2 version at this time, and our canary has been successfully released!
Originality is not easy, please indicate the source for reprinting: https://blog.csdn.net/weixin_40228200