Y57. Chapter III kubernetes from entry to proficiency -- business image version upgrade and rollback (30)

12.3 Rolling update and rollback

At the designated deployment Pass through kubectl set image Specify the new version of Mirror image :tag To achieve the purpose of updating the code .

Build three different versions of nginx Mirror image , For the first time v1 edition , The latter group is gradually upgraded to v2 And v3, Test the image version upgrade and rollback operation

deployment The controller supports two update strategies ： The default is scrolling 
1. Scroll to update (rolling update)：
 Rolling update is the default update strategy , Rolling update is to create a new version based on the new version image pod, Then delete some old versions pod, Then create a new version pod, Delete some old versions pod, Until the version pod Delete complete , The advantage of rolling update is that the service will not be unavailable during the upgrade process , The disadvantage is that during the upgrade process, two versions will coexist in a short time .
 The specific upgrade process is after the update operation k8s A new version will be created ReplicaSet controller , Deleting the old version ReplicaSet Under the controller pod At the same time, it will be in the new version ReplicaSet Create a new pod, Until the old version pod After all are deleted, put the version ReplicaSet The controller is also recycled .

 While performing the rolling update , In order to ensure the availability of services , Not available in the current controller pod(pod It is necessary to pull the image, which is not available during creation and probe detection ) Cannot exceed a certain range , Because at least a certain amount of pod To ensure that the service can be accessed by the client normally , Can be specified by the following parameters ：