本篇内容介绍了“Kubernetes Deployment滚动更新机制是什么”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
定义Deployment时与rolling update的相关项
以下面的frontend Deployment为例，重点关注.spec.minReadySeconds,.spec.strategy.rollingUpdate.maxSurge,.spec.strategy.rollingUpdate. maxUnavailable。
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: frontend
spec:
minReadySeconds: 5
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 3
maxUnavailable: 2
replicas: 25
template:
metadata:
labels:
app: guestbook
tier: frontend
spec:
containers:
- name: php-redis
image: gcr.io/google-samples/gb-frontend:v4
resources:
requests:
cpu: 100m
memory: 100Mi
env:
- name: GET_HOSTS_FROM
value: dns
# If your cluster config does not include a dns service, then to
# instead access environment variables to find service host
# info, comment out the 'value: dns' line above, and uncomment the
# line below:
# value: env
ports:
- containerPort: 80
.spec.minReadySeconds: 新创建的Pod状态为Ready持续的时间至少为.spec.minReadySeconds才认为Pod Available(Ready)。
.spec.strategy.rollingUpdate.maxSurge: specifies the maximum number of Pods that can be created over the desired number of Pods. The value cannot be 0 if MaxUnavailable is 0. 可以为整数或者百分比，默认为desired Pods数的25%. Scale Up新的ReplicaSet时，按照比例计算出允许的MaxSurge，计算时向上取整(比如3.4，取4)。
.spec.strategy.rollingUpdate.maxUnavailable: specifies the maximum number of Pods that can be unavailable during the update process. The value cannot be 0 if maxSurge is 0.可以为整数或者百分比，默认为desired Pods数的25%. Scale Down旧的ReplicaSet时，按照比例计算出允许的maxUnavailable，计算时向下取整(比如3.6，取3)。
因此，在Deployment rollout时，需要保证Available(Ready) Pods数不低于 desired pods number - maxUnavailable; 保证所有的Pods数不多于 desired pods number + maxSurge。
滚动更新的流程
Note: A Deployment’s rollout is triggered if and only if the Deployment’s pod template (that is, .spec.template) is changed, for example if the labels or container images of the template are updated. Other updates, such as scaling the Deployment, do not trigger a rollout.
我们继续以上面的Deployment为例子，并考虑最常用的情况--更新image（发布新版本）:
kubectl set image deploy frontend php-redis=gcr.io/google-samples/gb-frontend:v3 --record
set image之后，导致Deployment's Pod Template发生变化，就会触发rollout。我们只考虑RollingUpdate策略（Kubernetes还支持ReCreate更新策略）。通过kubectl get rs -w来watch ReplicaSet的变化。
[root@master03 ~]# kubectl get rs -w
NAME DESIRED CURRENT READY AGE
frontend-3114648124 25 25 25 14m
frontend-3099797709 0 0 0 1h
frontend-3099797709 0 0 0 1h
frontend-3099797709 3 0 0 1h
frontend-3114648124 23 25 25 17m
frontend-3099797709 5 0 0 1h
frontend-3114648124 23 25 25 17m
frontend-3114648124 23 23 23 17m
frontend-3099797709 5 0 0 1h
frontend-3099797709 5 3 0 1h
frontend-3099797709 5 5 0 1h
frontend-3099797709 5 5 1 1h
frontend-3114648124 22 23 23 17m
frontend-3099797709 5 5 2 1h
frontend-3114648124 22 23 23 17m
frontend-3114648124 22 22 22 17m
frontend-3099797709 6 5 2 1h
frontend-3114648124 21 22 22 17m
frontend-3099797709 6 5 2 1h
frontend-3114648124 21 22 22 17m
frontend-3099797709 7 5 2 1h
frontend-3099797709 7 6 2 1h
frontend-3114648124 21 21 21 17m
frontend-3099797709 7 6 2 1h
frontend-3099797709 7 7 2 1h
frontend-3099797709 7 7 2 1h
frontend-3099797709 7 7 3 1h
frontend-3099797709 7 7 4 1h
frontend-3114648124 20 21 21 17m
frontend-3099797709 8 7 4 1h
frontend-3114648124 20 21 21 17m
frontend-3114648124 20 20 20 17m
frontend-3099797709 8 7 4 1h
frontend-3099797709 8 8 4 1h
frontend-3099797709 8 8 5 1h
frontend-3114648124 19 20 20 17m
frontend-3099797709 9 8 5 1h
frontend-3114648124 19 20 20 17m
frontend-3099797709 9 8 5 1h
frontend-3099797709 9 9 5 1h
frontend-3114648124 19 19 19 17m
frontend-3099797709 9 9 5 1h
frontend-3114648124 18 19 19 18m
frontend-3099797709 10 9 5 1h
frontend-3114648124 18 19 19 18m
frontend-3099797709 10 9 5 1h
frontend-3114648124 18 18 18 18m
frontend-3099797709 10 10 5 1h
frontend-3099797709 10 10 5 1h
frontend-3114648124 18 18 18 18m
frontend-3099797709 10 10 6 1h
frontend-3099797709 10 10 6 1h
frontend-3114648124 17 18 18 18m
frontend-3114648124 17 18 18 18m
frontend-3099797709 11 10 6 1h
frontend-3099797709 11 10 6 1h
frontend-3114648124 17 17 17 18m
frontend-3099797709 11 11 6 1h
说明：
frontend-3114648124为原来的RS（成为OldRS），frontend-3099797709为新建的RS（成为NewRS，当然也可能是Old RS，如果之前执行过这个一样的内容）。
maxSurge:3, maxUnavailable=2, desired replicas=25
NewRS创建maxSurge(3)个Pods，这时达到pods数的上限值desired replicas + maxSurge (28个）
不会等NewRS创建的Pods Ready，而是马上delete OldRS maxUnavailable(2)个Pods，这时Ready的Pods number最差也能保证desired replicas - maxUnavailable(23个)
接下来的流程是不固定，只要新建的Pods有几个返回Ready，则意味着可以接着删除几个旧的Pods了。只要有几个删除成功的Pods返回，就会创建一定数量的Pods，只要All pods数量与上限值desired replicas + maxSurge有差值空间，就会接着创建新的Pods。
如此进行滚动更新， 直到创建的新Pods个数达到desired replicas，并等待它们都Ready，然后再删除所有剩余的旧的Pods。至此，滚动流程结束。
对同一个Deployment先后触发滚动更新，逻辑如何？
我们考虑这个情况，但用户执行某个滚动更新后，未等待此次滚动更新结束，就继续执行了一次新的滚动更新请求，这时后台滚动流程会怎么样呢？会乱成一锅粥么？
我们继续以这个例子来看：
# deploy frontend 稳定运行在v2(frontend-888714875)时：
[root@master03 ~]# kubectl get rs -w
NAME DESIRED CURRENT READY AGE
====执行 kubectl set image deploy frontend php-redis=gcr.io/google-samples/gb-frontend:v3 --record
----备注： v3 --> frontend-776431694
frontend-776431694 0 0 0 6h
frontend-776431694 0 0 0 6h
frontend-776431694 3 0 0 6h
frontend-888714875 23 25 25 5h
frontend-776431694 5 0 0 6h
frontend-888714875 23 25 25 5h
frontend-888714875 23 23 23 5h
frontend-776431694 5 0 0 6h
frontend-776431694 5 3 0 6h
frontend-776431694 5 5 0 6h
frontend-776431694 5 5 1 6h
frontend-776431694 5 5 2 6h
frontend-776431694 5 5 3 6h
frontend-776431694 5 5 4 6h
frontend-776431694 5 5 4 6h
frontend-888714875 22 23 23 5h
frontend-776431694 6 5 4 6h
frontend-888714875 22 23 23 5h
frontend-888714875 22 22 22 5h
frontend-776431694 6 5 4 6h
frontend-776431694 6 6 4 6h
frontend-776431694 6 6 4 6h
frontend-888714875 19 22 22 5h
frontend-776431694 9 6 4 6h
frontend-888714875 19 22 22 5h
frontend-776431694 9 6 4 6h
frontend-888714875 19 19 19 5h
frontend-776431694 9 9 4 6h
frontend-888714875 19 19 19 5h
==== 执行 kubectl set image deploy frontend php-redis=gcr.io/google-samples/gb-frontend:v4 --record ====
----- 备注：v4 --> frontend-3099797709 ----
frontend-3099797709 0 0 0 6h
frontend-3099797709 0 0 0 6h
frontend-776431694 4 9 4 6h
frontend-3099797709 5 0 0 6h
frontend-3099797709 5 0 0 6h
frontend-3099797709 5 5 0 6h
frontend-776431694 4 9 4 6h
frontend-776431694 4 4 4 6h
frontend-3099797709 5 5 0 6h
frontend-3099797709 5 5 1 6h
frontend-3099797709 5 5 2 6h
frontend-3099797709 5 5 3 6h
frontend-3099797709 5 5 4 6h
frontend-3099797709 5 5 4 6h
frontend-776431694 2 4 4 6h
frontend-3099797709 7 5 4 6h
frontend-776431694 2 4 4 6h
frontend-776431694 2 2 2 6h
frontend-776431694 2 2 2 6h
frontend-3099797709 7 5 4 6h
frontend-776431694 0 2 2 6h
frontend-3099797709 7 7 4 6h
frontend-776431694 0 2 2 6h
frontend-3099797709 9 7 4 6h
frontend-776431694 0 0 0 6h
frontend-3099797709 9 7 4 6h
frontend-3099797709 9 9 4 6h
frontend-776431694 0 0 0 6h
frontend-3099797709 9 9 4 6h
frontend-3099797709 9 9 5 6h
frontend-3099797709 9 9 6 6h
frontend-3099797709 9 9 7 6h
frontend-888714875 17 19 19 5h
frontend-3099797709 11 9 7 6h
frontend-888714875 17 19 19 5h
frontend-888714875 17 17 17 5h
frontend-3099797709 11 9 7 6h
frontend-888714875 16 17 17 5h
frontend-3099797709 11 11 7 6h
frontend-3099797709 12 11 7 6h
frontend-888714875 16 17 17 5h
frontend-888714875 16 16 16 5h
frontend-3099797709 12 11 7 6h
frontend-3099797709 12 12 7 6h
frontend-3099797709 12 12 8 6h
frontend-3099797709 12 12 8 6h
frontend-888714875 15 16 16 5h
frontend-3099797709 13 12 8 6h
frontend-888714875 15 16 16 5h
frontend-888714875 15 15 15 5h
frontend-3099797709 13 12 8 6h
frontend-3099797709 13 13 8 6h
frontend-3099797709 13 13 8 6h
frontend-3099797709 13 13 9 6h
frontend-3099797709 13 13 10 6h
frontend-888714875 14 15 15 5h
frontend-3099797709 14 13 10 6h
frontend-888714875 14 15 15 5h
frontend-888714875 14 14 14 5h
frontend-3099797709 14 13 10 6h
frontend-888714875 14 14 14 5h
frontend-3099797709 14 14 11 6h
frontend-3099797709 14 14 12 6h
frontend-3099797709 14 14 12 6h
frontend-3099797709 14 14 12 6h
frontend-888714875 11 14 14 5h
frontend-3099797709 17 14 12 6h
frontend-888714875 11 14 14 5h
frontend-3099797709 17 14 12 6h
frontend-888714875 11 11 11 5h
frontend-3099797709 17 17 12 6h
frontend-888714875 11 11 11 5h
frontend-3099797709 17 17 12 6h
frontend-3099797709 17 17 13 6h
frontend-3099797709 17 17 14 6h
frontend-3099797709 17 17 14 6h
frontend-888714875 10 11 11 5h
frontend-3099797709 18 17 14 6h
frontend-888714875 10 11 11 5h
frontend-888714875 10 10 10 5h
frontend-3099797709 18 17 14 6h
frontend-3099797709 18 18 14 6h
frontend-3099797709 18 18 15 6h
frontend-888714875 9 10 10 5h
frontend-3099797709 18 18 16 6h
frontend-888714875 9 10 10 5h
frontend-3099797709 19 18 16 6h
frontend-3099797709 19 18 16 6h
frontend-888714875 9 9 9 5h
frontend-888714875 7 9 9 5h
frontend-3099797709 19 18 16 6h
frontend-888714875 7 9 9 5h
frontend-3099797709 21 18 16 6h
frontend-888714875 7 9 9 5h
frontend-3099797709 21 19 16 6h
frontend-888714875 7 7 7 5h
frontend-3099797709 21 21 16 6h
frontend-888714875 7 7 7 5h
frontend-3099797709 21 21 17 6h
frontend-3099797709 21 21 18 6h
frontend-3099797709 21 21 18 6h
frontend-888714875 5 7 7 5h
frontend-888714875 5 7 7 5h
frontend-3099797709 23 21 18 6h
frontend-888714875 5 5 5 5h
frontend-3099797709 23 21 18 6h
frontend-3099797709 23 23 18 6h
frontend-3099797709 23 23 18 6h
frontend-3099797709 23 23 19 6h
frontend-3099797709 23 23 20 6h
frontend-3099797709 23 23 20 6h
frontend-888714875 3 5 5 5h
frontend-3099797709 25 23 20 6h
frontend-888714875 3 5 5 5h
frontend-888714875 3 3 3 5h
frontend-3099797709 25 23 20 6h
frontend-888714875 3 3 3 5h
frontend-3099797709 25 25 20 6h
frontend-3099797709 25 25 21 6h
frontend-3099797709 25 25 22 6h
frontend-3099797709 25 25 22 6h
frontend-888714875 2 3 3 5h
frontend-888714875 2 3 3 5h
frontend-888714875 2 2 2 5h
frontend-888714875 2 2 2 5h
frontend-3099797709 25 25 23 6h
frontend-888714875 1 2 2 5h
frontend-888714875 1 2 2 5h
frontend-888714875 1 1 1 5h
frontend-3099797709 25 25 23 6h
frontend-888714875 0 1 1 5h
frontend-888714875 0 1 1 5h
frontend-888714875 0 0 0 5h
frontend-3099797709 25 25 24 6h
frontend-3099797709 25 25 25 6h
frontend-3099797709 25 25 25 6h
说明：
deployment frontend稳定运行在v2版本(RS：frontend-888714875)，然后执行kubectl set image触发滚动更新到v3版本（RS: frontend-776431694）, 当v3 RS的desired个数scale up到9个，ready个数为4个时，用户又执行kubectl set image触发滚动更新到v4版本（RS: frontend-3099797709）。
v2到v3的滚动流程同上一小节的描述；
当新的滚动流程触发后，最老的v2的RS保持不动，不会继续scale down。
然后v4将通过滚动更新的方式把已经scale up的9个v3 RS的pods替换掉，将所有v3的Pods升级到v4。
最后再接着v4 RS滚动更新把v2的RS所有的旧Pods都升级到v4。
整个完整的滚动流程中，都必须遵守maxSurge和maxUnavailable的约束，不能越雷池半步。
设想一个更复杂的场景：如果在上述v4滚动更新替换到半吊子的v3 RS过程中，用户又触发了一个滚动更新到v5版本，流程会怎么样呢？ 不要怕，原理是一样的，Deployment rolling update总是先把最新的RS滚动更新替换掉，然后逐步把旧的RS滚动更新替换掉，直到最最老的那个RS scale down为0，流程就结束了，可以简要概括如下：
剩余的v2, v3停止scale down；
v5把v4通过滚动更新的方式替换掉;
v5再把剩余v3通过滚动更新的方式替换掉;
v5再把剩余v2通过滚动更新的方式替换掉;
最后的RS会按照RS从新到旧排序的方式，逐步把旧的RS Pods scale down to 0， 自己 scale up to desired pods number。
理解rollout pause和resume
或许很多人至今还会这么觉得：整个滚动更新的过程中，一旦用户执行了kubectl rollout pause deploy/frontend后，正在执行的滚动流程就会立刻停止，然后用户执行kubectl rollout resume deploy/frontend就会继续未完成的滚动更新。那你就大错特错了！
kubectl rollout pause只会用来停止触发下一次rollout。什么意思呢？ 上面描述的这个场景，正在执行的滚动历程是不会停下来的，而是会继续正常的进行滚动，直到完成。等下一次，用户再次触发rollout时，Deployment就不会真的去启动执行滚动更新了，而是等待用户执行了kubectl rollout resume，流程才会真正启动执行。
ReplicaSet和rollout history的关系
前提，你要知道关于--record：
Setting the kubectl flag --record to true allows you to record current command in the annotations of the resources being created or updated.
默认情况下，所有通过kubectl xxxx --record都会被kubernetes记录到etcd进行持久化，这无疑会占用资源，最重要的是，时间久了，当你kubectl get rs时，会有成百上千的垃圾RS返回给你，那时你可能就眼花缭乱了。
上生产时，我们最好通过设置Deployment的.spec.revisionHistoryLimit来限制最大保留的revision number，比如15个版本，回滚的时候一般只会回滚到最近的几个版本就足够了。
执行下面的命令，可以返回某个Deployment的所有record记录：
$ kubectl rollout history deployment/nginx-deployment
deployments "nginx-deployment"
REVISION CHANGE-CAUSE
1 kubectl create -f docs/user-guide/nginx-deployment.yaml --record
2 kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
3 kubectl set image deployment/nginx-deployment nginx=nginx:1.91
然后执行rollout undo命令就可以回滚到to-revision指定的版本。
kubectl rollout undo deployment/nginx-deployment --to-revision=2
deployment "nginx-deployment" rolled back
其实rollout history中记录的revision都和ReplicaSets一一对应。如果手动delete某个ReplicaSet，对应的rollout history就会被删除，也就是还说你无法回滚到这个revison了。
roolout history和ReplicaSet的对应关系，可以在kubectl describe rs $RSNAME返回的revision字段中得到，这里的revision就对应着roolout history返回的revison。
“Kubernetes Deployment滚动更新机制是什么”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注天达云网站，小编将为大家输出更多高质量的实用文章！