K8s控制器Deployment详解

回顾 ReplicaSet 控制器,该控制器是用来维护集群中运行的 Pod 数量的，但是往往在实际操纵的时间，我们反而不会去直接利用 RS，而是会利用更上层的控制器，比如说 Deployment。
Deployment 一个非常紧张的功能就是实现了 Pod 的滚动更新，比如我们应用更新了，我们只须要更新我们的容器镜像，然后修改 Deployment 内里的 Pod 模板镜像，那么 Deployment 就会用滚动更新（Rolling Update）的方式来升级如今的 Pod，这个能力黑白常紧张的，因为对于线上的服务我们须要做到不中断服务，所以滚动更新就成了必须的一个功能。而 Deployment 这个能力的实现，依靠的就是ReplicaSet 这个资源对象。
线上应用建议利用 kubectl rollout restart 进行平滑重启，避免 kubectl delete pod 造成短暂不可用。
回滚时，先用 kubectl rollout history 确承认用版本，然后执行 kubectl rollout undo。
更新过程中，可利用 kubectl rollout pause 和 resume 进行分阶段部署。
Deployment 资源对象的格式和 ReplicaSet 险些同等，如下资源对象就是一个常见的 Deployment 资源类型。
创建下这个资源对象，查察 Pod 状态：

1. $ kubectl apply -f - << EOF
2. apiVersion: apps/v1
3. kind: Deployment  
4. metadata:
5.   name:  nginx-deploy
6.   namespace: default
7. spec:
8.   replicas: 3  # 期望的 Pod 副本数量，默认值为1
9.   selector:  # Label Selector，必须匹配 Pod 模板中的标签
10.     matchLabels:
11.       app: nginx
12.   template:  # Pod 模板
13.     metadata:
14.       labels:
15.         app: nginx
16.     spec:
17.       containers:
18.       - name: nginx
19.         image: nginx
20.         ports:
21.         - containerPort: 80
22. EOF
24. $ kubectl get deployment
25. NAME           READY   UP-TO-DATE   AVAILABLE   AGE
26. nginx-deploy   3/3     3            3           58s
28. $ kubectl get pods -l app=nginx
29. NAME                            READY   STATUS    RESTARTS   AGE
30. nginx-deploy-85ff79dd56-7r76h   1/1     Running   0          41s
31. nginx-deploy-85ff79dd56-d5gjs   1/1     Running   0          41s
32. nginx-deploy-85ff79dd56-txc4h   1/1     Running   0          41s

复制代码

到这里我们发现和之前的 RS 对象是否没有什么两样，都是根据spec.replicas来维持的副本数量，我们随意查察一个 Pod 的形貌信息：

1. $ kubectl describe pod nginx-deploy-85ff79dd56-txc4h | grep Controlled
2. Controlled By:      ReplicaSet/nginx-deploy-85ff79dd56

复制代码

我们细致查察其中有这样一个信息Controlled By: ReplicaSet/nginx-deploy-85ff79dd56，什么意思？是不是表现当前我们这个 Pod 的控制器是一个 ReplicaSet 对象啊，我们不是创建的一个 Deployment 吗？为什么 Pod 会被 RS 所控制呢？那我们再去看下这个对应的 RS 对象的详细信息怎样呢：

1. $ kubectl describe rs nginx-deploy-85ff79dd56
2. Name:           nginx-deploy-85ff79dd56
3. Namespace:      default
4. Selector:       app=nginx,pod-template-hash=85ff79dd56
5. Labels:         app=nginx
6.                 pod-template-hash=85ff79dd56
7. Annotations:    deployment.kubernetes.io/desired-replicas: 3
8.                 deployment.kubernetes.io/max-replicas: 4
9.                 deployment.kubernetes.io/revision: 1
10. Controlled By:  Deployment/nginx-deploy
11. Replicas:       3 current / 3 desired
12. Pods Status:    3 Running / 0 Waiting / 0 Succeeded / 0 Failed
13. ......
14. Events:
15.   Type    Reason            Age    From                   Message
16.   ----    ------            ----   ----                   -------
17.   Normal  SuccessfulCreate  4m52s  replicaset-controller  Created pod: nginx-deploy-85ff79dd56-7r76h
18.   Normal  SuccessfulCreate  4m52s  replicaset-controller  Created pod: nginx-deploy-85ff79dd56-d5gjs
19.   Normal  SuccessfulCreate  4m52s  replicaset-controller  Created pod: nginx-deploy-85ff79dd56-txc4h

复制代码

其中有这样的一个信息：Controlled By: Deployment/nginx-deploy，明白了吧？意思就是我们的 Pod 依靠的控制器 RS 实际上被我们的 Deployment 控制着呢，我们可以用下图来阐明 Pod、ReplicaSet、Deployment 三者之间的关系：

通过上图我们可以很清楚的看到，定义了3个副本的 Deployment 与 ReplicaSet 和 Pod 的关系，就是一层一层进行控制的。ReplicaSet 作用和之前一样还是来保证 Pod 的个数始终生存指定的数量，所以 Deployment 中的容器 restartPolicy只能是Always 就是这个原因，因为容器必须始终保证本身处于 Running 状态，ReplicaSet 才可以去明白调解 Pod 的个数。而 Deployment 是通过管理 ReplicaSet 的数量和属性来实现程度扩展/收缩以及滚动更新两个功能的。
程度伸缩

程度扩展/收缩的功能比较简单，因为 ReplicaSet 就可以实现，所以 Deployment 控制器只须要去修改它缩控制的 ReplicaSet 的 Pod 副本数量就可以了。比如如今我们把 Pod 的副本调解到 4 个，那么 Deployment 所对应的 ReplicaSet 就会自动创建一个新的 Pod 出来，这样就程度扩展了，我们可以利用一个新的命令 kubectl scale 命令来完成这个操纵：

1. $ kubectl scale deployment nginx-deploy --replicas=4
2. deployment.apps/nginx-deployment scaled

复制代码

扩展完成后可以查察当前的 RS 对象：

1. $ kubectl get rs
2. NAME                      DESIRED   CURRENT   READY   AGE
3. nginx-deploy-85ff79dd56   4         4         3       40m

复制代码

可以看到盼望的 Pod 数量已经变成 4 了，只是 Pod 还没准备完成，所以 READY 状态数量还是 3，同样查察 RS 的详细信息：

1. $ kubectl describe rs nginx-deploy-85ff79dd56
2. Name:           nginx-deploy-85ff79dd56
3. Namespace:      default
4. Selector:       app=nginx,pod-template-hash=85ff79dd56
5. ......
6. Events:
7.   Type    Reason            Age   From                   Message
8.   ----    ------            ----  ----                   -------
9.   Normal  SuccessfulCreate  40m   replicaset-controller  Created pod: nginx-deploy-85ff79dd56-7r76h
10.   Normal  SuccessfulCreate  40m   replicaset-controller  Created pod: nginx-deploy-85ff79dd56-d5gjs
11.   Normal  SuccessfulCreate  40m   replicaset-controller  Created pod: nginx-deploy-85ff79dd56-txc4h
12.   Normal  SuccessfulCreate  17s   replicaset-controller  Created pod: nginx-deploy-85ff79dd56-tph9g

复制代码

可以看到 ReplicaSet 控制器增长了一个新的 Pod，同样的 Deployment 资源对象的事件中也可以看到完成了扩容的操纵：

1. $ kubectl describe deploy nginx-deploy
2. Name:                   nginx-deploy
3. Namespace:              default
4. ......
5. OldReplicaSets:  <none>
6. NewReplicaSet:   nginx-deploy-85ff79dd56 (4/4 replicas created)
7. Events:
8.   Type    Reason             Age    From                   Message
9.   ----    ------             ----   ----                   -------
10.   Normal  ScalingReplicaSet  43m    deployment-controller  Scaled up replica set nginx-deploy-85ff79dd56 to 3
11.   Normal  ScalingReplicaSet  3m16s  deployment-controller  Scaled up replica set nginx-deploy-85ff79dd56 to 4

复制代码

滚动更新

假如只是程度扩展/收缩这两个功能，就完全没须要设计 Deployment 这个资源对象了，Deployment 最突出的一个功能是支持滚动更新，比如如今我们须要把应用容器更改为 nginx:1.7.9 版本，修改后的资源清单文件如下所示：

1. apiVersion: apps/v1
2. kind: Deployment  
3. metadata:
4.   name:  nginx-deploy
5.   namespace: default
6. spec:
7.   replicas: 3  
8.   selector:  
9.     matchLabels:
10.       app: nginx
11.   minReadySeconds: 5
12.   strategy:  
13.     type: RollingUpdate  # 指定更新策略：RollingUpdate和Recreate
14.     rollingUpdate:
15.       maxSurge: 1
16.       maxUnavailable: 1
17.   template:  
18.     metadata:
19.       labels:
20.         app: nginx
21.     spec:
22.       containers:
23.       - name: nginx
24.         image: nginx:1.7.9
25.         ports:
26.         - containerPort: 80

复制代码

后前面相比较，除了更改了镜像之外，我们还指定了更新计谋：

1. minReadySeconds: 5
2. strategy:
3.   type: RollingUpdate
4.   rollingUpdate:
5.     maxSurge: 1
6.     maxUnavailable: 1

复制代码

• minReadySeconds：表现 Kubernetes 在等待设置的时间后才进行升级，假如没有设置该值，Kubernetes 会假设该容器启动起来后就提供服务了，假如没有设置该值，在某些极度环境下可能会造成服务不正常运行，默认值就是0。
  
• type=RollingUpdate：表现设置更新计谋为滚动更新，可以设置为Recreate和RollingUpdate两个值，Recreate表现全部重新创建，默认值就是RollingUpdate。
  
• maxSurge：表现升级过程中最多可以比原先设置多出的 Pod 数量，例如：maxSurage=1，replicas=5，就表现Kubernetes 会先启动一个新的 Pod，然后才删掉一个旧的 Pod，整个升级过程中最多会有5+1个 Pod。
  
• maxUnavaible：表现升级过程中最多有多少个 Pod 处于无法提供服务的状态，例如：maxUnavaible=1，则表现 Kubernetes 整个升级过程中最多会有1个 Pod 处于无法服务的状态。
  

✅ maxSurge 和 maxUnavailable 不能同时为 0，否则 Deployment 无法完成滚动更新。
• 至少有一个大于 0，否则 Pod 无法被替换。
• 推荐 maxSurge: 25%、maxUnavailable: 25%，兼顾可用性和更新速度。
• maxSurge: 1, maxUnavailable: 0 实用于高可用业务，确保无中断更新。
• maxSurge: 0, maxUnavailable: 1 实用于资源受限场景，节省资源但更新更慢。
如今我们来直接更新上面的 Deployment 资源对象：

1. $ kubectl apply -f nginx-deploy.yaml

复制代码

更新后，我们可以执行下面的 kubectl rollout status 命令来查察我们此次滚动更新的状态：

1. $ kubectl rollout status deployment/nginx-deploy
2. Waiting for deployment "nginx-deploy" rollout to finish: 2 out of 3 new replicas have been updated...

复制代码

从上面的信息可以看出我们的滚动更新已经有两个 Pod 已经更新完成了，在滚动更新过程中，我们还可以执行如下的命令来暂停更新：

1. $ kubectl rollout pause deployment/nginx-deploy
2. deployment.apps/nginx-deploy paused

复制代码

这个时间我们的滚动更新就暂停了，此时我们可以查察下 Deployment 的详细信息：

1. $ kubectl describe deploy nginx-deploy
2. Name:                   nginx-deploy
3. Namespace:              default
4. CreationTimestamp:      Sat, 16 Nov 2019 16:01:24 +0800
5. Labels:                 <none>
6. Annotations:            deployment.kubernetes.io/revision: 2
7.                         kubectl.kubernetes.io/last-applied-configuration:
8.                           {"apiVersion":"apps/v1","kind":"Deployment","metadata":{"annotations":{},"name":"nginx-deploy","namespace":"default"},"spec":{"minReadySec...
9. Selector:               app=nginx
10. Replicas:               3 desired | 2 updated | 4 total | 4 available | 0 unavailable
11. StrategyType:           RollingUpdate
12. MinReadySeconds:        5
13. RollingUpdateStrategy:  1 max unavailable, 1 max surge
14. ......
15. OldReplicaSets:  nginx-deploy-85ff79dd56 (2/2 replicas created)
16. NewReplicaSet:   nginx-deploy-5b7b9ccb95 (2/2 replicas created)
17. Events:
18.   Type    Reason             Age    From                   Message
19.   ----    ------             ----   ----                   -------
20.   Normal  ScalingReplicaSet  26m    deployment-controller  Scaled up replica set nginx-deploy-85ff79dd56 to 4
21.   Normal  ScalingReplicaSet  3m44s  deployment-controller  Scaled down replica set nginx-deploy-85ff79dd56 to 3
22.   Normal  ScalingReplicaSet  3m44s  deployment-controller  Scaled up replica set nginx-deploy-5b7b9ccb95 to 1
23.   Normal  ScalingReplicaSet  3m44s  deployment-controller  Scaled down replica set nginx-deploy-85ff79dd56 to 2
24.   Normal  ScalingReplicaSet  3m44s  deployment-controller  Scaled up replica set nginx-deploy-5b7b9ccb95 to 2

复制代码

我们细致观察 Events 事件地区的变化，上面我们用 kubectl scale 命令将 Pod 副本调解到了 4，如今我们更新的时间是不是声明又变成 3 了，所以 Deployment 控制器首先是将之前控制的 nginx-deploy-85ff79dd56 这个 RS 资源对象进行缩容操纵，然后滚动更新开始了，可以发现 Deployment 为一个新的 nginx-deploy-5b7b9ccb95 RS 资源对象首先新建了一个新的 Pod，然后将之前的 RS 对象缩容到 2 了，再然后新的 RS 对象扩容到 2，后面由于我们暂停滚动升级了，所以没有后续的事件了，各人有看明白这个过程吧？这个过程就是滚动更新的过程，启动一个新的 Pod，杀掉一个旧的 Pod，然后再启动一个新的 Pod，这样滚动更新下去，直到全都变成新的 Pod，这个时间系统中应该存在 4 个 Pod，因为我们设置的计谋maxSurge=1，所以在升级过程中是允许的，而且是两个新的 Pod，两个旧的 Pod：

1. $ kubectl get pods -l app=nginx
2. NAME                            READY   STATUS    RESTARTS   AGE
3. nginx-deploy-5b7b9ccb95-k6pkh   1/1     Running   0          11m
4. nginx-deploy-5b7b9ccb95-l6lmx   1/1     Running   0          11m
5. nginx-deploy-85ff79dd56-7r76h   1/1     Running   0          75m
6. nginx-deploy-85ff79dd56-txc4h   1/1     Running   0          75m

复制代码

查察 Deployment 的状态也可以看到当前的 Pod 状态：

1. $ kubectl get deployment  
2. NAME           READY   UP-TO-DATE   AVAILABLE   AGE
3. nginx-deploy   4/3     2            4           75m

复制代码

这个时间我们可以利用kubectl rollout resume来恢复我们的滚动更新：

1. $ kubectl rollout resume deployment/nginx-deploy
2. deployment.apps/nginx-deploy resumed
3. $ kubectl rollout status deployment/nginx-deploy
4. Waiting for deployment "nginx-deploy" rollout to finish: 2 of 3 updated replicas are available...
5. deployment "nginx-deploy" successfully rolled out

复制代码

看到上面的信息证明我们的滚动更新已经乐成了，同样可以查察下资源状态：

1. $ kubectl get pod -l app=nginx
2. NAME                            READY   STATUS    RESTARTS   AGE
3. nginx-deploy-5b7b9ccb95-gmq7v   1/1     Running   0          115s
4. nginx-deploy-5b7b9ccb95-k6pkh   1/1     Running   0          15m
5. nginx-deploy-5b7b9ccb95-l6lmx   1/1     Running   0          15m
6. $ kubectl get deployment                        
7. NAME           READY   UP-TO-DATE   AVAILABLE   AGE
8. nginx-deploy   3/3     3            3           79m

复制代码

这个时间我们查察 ReplicaSet 对象，可以发现会出现两个：

1. $ kubectl get rs -l app=nginx
2. NAME                      DESIRED   CURRENT   READY   AGE
3. nginx-deploy-5b7b9ccb95   3         3         3       18m
4. nginx-deploy-85ff79dd56   0         0         0       81m

复制代码

从上面可以看出滚动更新之前我们利用的 RS 资源对象的 Pod 副本数已经变成 0 了，而滚动更新后的 RS 资源对象变成了 3 个副本，我们可以导出之前的 RS 对象查察：

1. $ kubectl get rs nginx-deploy-85ff79dd56 -o yaml
2. apiVersion: apps/v1
3. kind: ReplicaSet
4. metadata:
5.   annotations:
6.     deployment.kubernetes.io/desired-replicas: "3"
7.     deployment.kubernetes.io/max-replicas: "4"
8.     deployment.kubernetes.io/revision: "1"
9.   creationTimestamp: "2019-11-16T08:01:24Z"
10.   generation: 5
11.   labels:
12.     app: nginx
13.     pod-template-hash: 85ff79dd56
14.   name: nginx-deploy-85ff79dd56
15.   namespace: default
16.   ownerReferences:
17.   - apiVersion: apps/v1
18.     blockOwnerDeletion: true
19.     controller: true
20.     kind: Deployment
21.     name: nginx-deploy
22.     uid: b0fc5614-ef58-496c-9111-740353bd90d4
23.   resourceVersion: "2140545"
24.   selfLink: /apis/apps/v1/namespaces/default/replicasets/nginx-deploy-85ff79dd56
25.   uid: 8eca2998-3610-4f80-9c21-5482ba579892
26. spec:
27.   replicas: 0
28.   selector:
29.     matchLabels:
30.       app: nginx
31.       pod-template-hash: 85ff79dd56
32.   template:
33.     metadata:
34.       creationTimestamp: null
35.       labels:
36.         app: nginx
37.         pod-template-hash: 85ff79dd56
38.     spec:
39.       containers:
40.       - image: nginx
41.         imagePullPolicy: Always
42.         name: nginx
43.         ports:
44.         - containerPort: 80
45.           protocol: TCP
46.         resources: {}
47.         terminationMessagePath: /dev/termination-log
48.         terminationMessagePolicy: File
49.       dnsPolicy: ClusterFirst
50.       restartPolicy: Always
51.       schedulerName: default-scheduler
52.       securityContext: {}
53.       terminationGracePeriodSeconds: 30
54. status:
55.   observedGeneration: 5
56.   replicas: 0

复制代码

我们细致观察这个资源对象内里的形貌信息除了副本数变成了replicas=0之外，和更新之前没有什么区别吧？各人看到这里想到了什么？有了这个 RS 的纪录存在，是不是我们就可以回滚了啊？而且还可以回滚到前面的恣意一个版本，这个版本是怎样定义的呢？我们可以通过命令 rollout history 来获取：

1. $ kubectl rollout history deployment nginx-deploy
2. deployment.apps/nginx-deploy
3. REVISION  CHANGE-CAUSE
4. 1         <none>
5. 2         <none>

复制代码

其实 rollout history 中纪录的 revision 是和 ReplicaSets 一一对应。假如我们手动删除某个 ReplicaSet，对应的rollout history就会被删除，也就是说你无法回滚到这个revison了，同样我们还可以查察一个revison的详细信息：

1. $ kubectl rollout history deployment nginx-deploy --revision=1
2. deployment.apps/nginx-deploy with revision #1
3. Pod Template:
4.   Labels:       app=nginx
5.         pod-template-hash=85ff79dd56
6.   Containers:
7.    nginx:
8.     Image:      nginx
9.     Port:       80/TCP
10.     Host Port:  0/TCP
11.     Environment:        <none>
12.     Mounts:     <none>
13.   Volumes:      <none>

复制代码

假如如今要直接回退到当前版本的前一个版本，我们可以直接利用如下命令进行操纵：

1. $ kubectl rollout undo deployment nginx-deploy

复制代码

当然也可以回退到指定的revision版本：

1. $ kubectl rollout undo deployment nginx-deploy
2. --to-revision=1deployment "nginx-deploy" rolled back

复制代码

回滚的过程中我们同样可以查察回滚状态：

1. $ kubectl rollout status deployment/nginx-deploy
2. Waiting for deployment "nginx-deploy" rollout to finish: 1 old replicas are pending termination...
3. Waiting for deployment "nginx-deploy" rollout to finish: 1 old replicas are pending termination...
4. Waiting for deployment "nginx-deploy" rollout to finish: 1 old replicas are pending termination...
5. Waiting for deployment "nginx-deploy" rollout to finish: 2 of 3 updated replicas are available...
6. Waiting for deployment "nginx-deploy" rollout to finish: 2 of 3 updated replicas are available...
7. deployment "nginx-deploy" successfully rolled out

复制代码

这个时间查察对应的 RS 资源对象可以看到 Pod 副本已经回到之前的 RS 内里去了。

1. $ kubectl get rs -l app=nginx
2. NAME                      DESIRED   CURRENT   READY   AGE
3. nginx-deploy-5b7b9ccb95   0         0         0       31m
4. nginx-deploy-85ff79dd56   3         3         3       95m

复制代码

不外须要留意的是回滚的操纵滚动的revision始终是递增的：

1. $ kubectl rollout history deployment nginx-deploy
2. deployment.apps/nginx-deploy
3. REVISION  CHANGE-CAUSE
4. 2         <none>
5. 3         <none>

复制代码

生存旧版本
在很早之前的 Kubernetes 版本中，默认环境下会为我们袒露下所有滚动升级的汗青纪录，也就是 ReplicaSet 对象，但一般环境下没须要生存所有的版本，毕竟会存在 etcd 中，我们可以通过配置 spec.revisionHistoryLimit 属性来设置生存的汗青纪录数量，不外新版本中该值默认为 10，假如希望多生存几个版本可以设置该字段。
总结

1.deployment的spec.template发生变更的时间，Deployment会创建一个新的ReplicaSet，然后滚动更新Pod. 而更改spec.replicas的数量不会创建一个新的ReplicaSet。
2.maxSurge 和 maxUnavailable 不能同时为 0，否则 Deployment 无法完成滚动更新。
3.当deployment的spec发生变更时，generation会升级。
4.deployment的restartPolicy只能是Always.
5.spec.revisionHistoryLimit设置生存ReplicaSet的汗青纪录数量
常用命令

1. 调整副本数
2. kubectl scale deployment/<deployment-name> --replicas=4
3. 查看滚动更新状态
4. kubectl rollout status deployment/<deployment-name>
5. 暂停滚动更新
6. kubectl rollout pause deployment/<deployment-name>
7. 恢复滚动更新
8. kubectl rollout resume deployment/<deployment-name>
9. 回滚到指定版本
10. kubectl rollout undo deployment/<deployment-name> --to-revision=1
11. 回滚到上一个版本
12. kubectl rollout undo deployment/<deployment-name>
13. 查看历史版本
14. kubectl rollout history deployment/<deployment-name>
15. 查看指定版本的详情
16. kubectl rollout history deployment/<deployment-name> --revision=1
17. 重新启动 Deployment
18. kubectl rollout restart deployment/<deployment-name>

复制代码

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。