Deployment features
- Event and status viewing
- Save the updated version record, support rollback to the specified version
- A variety of automatic update schemes can be realized
- Pause and start, support the necessary pause for each upgrade, in order to continue the following updates
To put it bluntly, it is based on Pod-based advanced support for rolling updates. The features are all for updates
Deployment update
What is updated is the content under the Pod template, such as image files, tags, storage, etc., and how to update is done by the Deployment controller
- Update strategy: rolling update and re-creation
- Update and rollback methods: yaml file and command line
- Suspend the update plan: an update plan that is in line with the actual use
Update strategy
- Rolling update (default): The new and old versions are updated alternately, the advantage is that it can achieve theoretical non-disruptive updates
- Re-creation: Delete all the old versions and re-create the Pod according to the template. The disadvantage is that the business will be interrupted
The deployment update operation is still based on the replicaset controller, but the update process is based on the replacement of 2 controllers, the old version is reduced, and the new version adds
2 field descriptions for rolling update
- It is necessary to ensure the number of available Pods to ensure that the client can request the service normally, and this range number is controlled by 2 fields
- maxSurge: The maximum total number of copies (including old and new copies) that can be exceeded in the update, which can be a numerical value or a percentage. If 3 copies are defined, maxSurge=1,3+1=4
- maxSurge: The number of replicas available in the update (including old and new replicas), which can be a numeric value or a percentage. If 3 replicas are defined, maxUnavailable=1,3-1=2
maxSurge and maxSurge default to 25%
maxSurge and maxSurge can be 0, but cannot be 0 at the same time
View depolyment default update information
The implied meaning is that the new and old versions are replaced by a quarter of the update each time. This minimized implementation smoothly over-updates
Update method
Update Pod template information from the command line
- kubectl set: It can be directly written as an assignment to replace the content. The common image is image, which only supports part of the content
- kubectl set image deployment/nginx nginx=nginx:1.19.7
- Finally, nginx=nginx:1.19.7, which represents the mirror name=replaced mirror
- kubectl set image deployment/nginx nginx=nginx:1.19.7
- kubectl patch: replace content in json format
- kubectl patch deployment nginx --patch={“spec”: {“template”: {“spec”: {“containers”: [{“name”: “nginx”,“image”: “nginx:1.19.6”}]}}}}
Convert yaml format to json format: click to visit
yaml file update
- kubectl apply -f nginx-deploymnet.yaml --record
record is an execution command that can record historical versions
View the historical version, the first time is version 1, CHANGE-CAUSE is to add the record result, it is convenient to view the updated information
kubectl rollout history deployment nginx
spec.revisionHistoryLimit: historical version record, 5 historical records are recorded by default, more will be overwritten
kubectl rollout status deployment/nginx --revision=2
#查看更新状态
Rollback method
kubectl rollout undo deployment nginx --to-revision=2
REVISION has changed, the original 2 becomes 4 after rolling back, and the cumulative revision number is added
Suspend the update plan
The main purpose is to start a pause in the first batch of update Pod new and old updates. During the pause, you can test whether the new quarter of the application is normal, and then consider all the updates below. The first batch can be accurately controlled by maxSurge and maxSurge.
When the Deployment is suspended, any modification of PodTemplateSpec will not trigger a new launch
kubectl set image deployment/nginx nginx=nginx:1.19.7 && kubectl rollout pause deployment/nginx
#一般都是要更新后立即暂停,可以通过&&完成,也可以通过字段修改间隔时间
#字段spec.minReadySeconds,默认为0,可以改个几秒,方便操作暂停
View the history record, it prompts that a copy is being updated, and the follow-up has been suspended.
Resume operation
kubectl rollout resume deployment/nginx
Remaining problem
If I find that there is a problem when I pause, why don’t I update it directly, or roll back, the test does not seem to work, I still have to update first, and then roll back
Roll back during the suspension process, no, no instructions on the official website for the time being
Reference: Books: Advanced kubernetes combat-Ma Yongliang
Reference: https://kubernetes.io/zh/docs/concepts/workloads/controllers/deployment/