Table of contents
Canary Release/Grayscale Release (Canary Release)
1. Canary Release Introduction
2. Update the deployment version and configure to suspend the deployment
2.4 Define version change-cause
2.4.1 View historical versions
2.4.3 View the historical version again
2.4.4 Update nginx version to 1.15 and configure pause
Edit 2.4.5 Watch update status
2.4.6 Monitor the update process
2.4.8 View and update the historical version change-cause
2.4.9 resume to continue updating
2.4.10 View the last update status
Canary Release/Grayscale Release (Canary Release)
1. Canary Release Introduction
The Deployment controller supports custom control of the scrolling cadence during the update process , such as "pause" or "resume" the update operation. For example, wait for the first batch of new Pod resources to be created and immediately suspend the update process. At this time, only a part of the new version of the application exists, and the main part is still the old version. Then, after screening a small number of user requests and routing them to the new version of the Pod application, continue to observe whether it can run stably and as expected. After confirming that there is no problem, continue to complete the remaining Pod resource rolling update operations. This is known as a canary release.
2. Update the deployment version and configure to suspend the deployment
2.1 create pods
kubectl create deployment nginx-test --image=nginx:1.14 --replicas=3
kubectl get pods,deploy -o wide
2.2 Publishing services
kubectl expose deploy nginx-test --port=80 --target-port=80 --name=nginx-service --type=NodePort
kubectl get svc -o wide
2.3 View nginx version
curl -I 192.168.109.11:31811
kubectl describe deployment nginx-test | grep Image
2.4 Define version change-cause
2.4.1 View historical versions
When CHANGE-CAUSE is not defined, the default value is that when there are many historical versions, it is not convenient for us to identify the version number when rolling back. Therefore, it is recommended to define CHANGE-CAUSE as the service version to help us identify the current service.
kubectl rollout history deploy/nginx-test
2.4.2 Definition version
Generally, change-cause is defined by modifying the configuration
[root@master ~]# kubectl edit deploy/nginx-test
......
kind: Deployment
metadata:
annotations:
#Downline can define historical version revision
deployment.kubernetes.io/revision: "1"
#Define change-cause
kubernetes.io in the annotations under the matadata item of Deployment as follows /change-cause: "nginx1.14"
…
2.4.3 View the historical version again
kubectl rollout history deploy/nginx-test
2.4.4 Update nginx version to 1.15 and configure pause
kubectl set image deploy/nginx-test nginx=nginx:1.15 && kubectl rollout pause deploy/nginx-test
2.4.5 Observe update status
kubectl rollout status deploy/nginx-test
2.4.6 Monitor the update process
It can be seen that a new pod has been added, but an old resource has not been deleted according to the expected state, because the pause command is used
kubectl get pods -w
2.4.7 View nginx version
kubectl get pod -o wide
2.4.8 View and update the historical version change-cause
kubectl rollout history deploy/nginx-test
[root@master ~]# kubectl edit deploy/nginx-test
kind: Deployment
metadata:
annotations:
#The downstream revision is automatically updated to 2
deployment.kubernetes.io/revision: "2"
#Modify the downstream change-cause as nginx1.15
kubernetes.io/change-cause: nginx1.15
2.4.9 resume to continue updating
Test the new version no problem continue to update
kubectl rollout resume deploy/nginx-test
2.4.10 View the last update status
kubectl get pods -w
