K8s rolling update

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
Insert picture description here2 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
Insert picture description here

View depolyment default update information
Insert picture description here

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 patch: replace content in json format
    • kubectl patch deployment nginx --patch={“spec”: {“template”: {“spec”: {“containers”: [{“name”: “nginx”,“image”: “nginx:1.19.6”}]}}}}

Insert picture description here

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

Insert picture description here

spec.revisionHistoryLimit: historical version record, 5 historical records are recorded by default, more will be overwritten

Insert picture description here

kubectl rollout status deployment/nginx  --revision=2
#查看更新状态

Insert picture description here

Rollback method

kubectl rollout undo deployment nginx --to-revision=2

Insert picture description hereREVISION 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.
Insert picture description here
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

Insert picture description hereRoll 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/

Guess you like

Origin blog.csdn.net/yangshihuz/article/details/113858821