阿里云《云原生》公开课笔记 第六章 应用编排与管理：Deployment

课程文字：https://edu.aliyun.com/lesson_1651_18354?spm=5176.10731542.0.0.349620behMwqhU#_18354

Deployment：管理部署发布的控制器

主要作用

• 定义一种pod的期望数量
• 配置pod发布方式
• 更新中发生问题，可以一键回滚

Deployment的yaml文件

• kubectl get deployment 命令可查看deployment总体情况
• kubectl get pod可以查看到部署的情况：Pod 的 ownerReferences 即 Pod 所属的 controller 资源，并不是 Deployment，而是一个 ReplicaSet。这个 ReplicaSet 的 name，其实是 nginx-deployment 加上 pod.template-hash，所有的 Pod 都是 ReplicaSet 创建出来的，而 ReplicaSet 它对应的某一个具体的 Deployment.template 版本。

更新镜像

• kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1
• kubectl 后面有一个 set image 固定写法，这里指的是设定镜像；其次是一个 deployment.v1.apps，这里也是一个固定写法，表明要操作的资源类型，deployment 是资源名、v1 是资源版本、apps 是资源组，这里也可以简写为 deployment 或者 deployment.apps，比如说写为 deployment 的时候，默认将使用 apps 组 v1 版本。
• 更新的 deployment 的 name，nginx-deployment；再往后的 nginx 其实指的是 template，也就是 Pod 中的 container.name；这里我们可以注意到：一个 Pod 中，其实可能存在多个 container，需要指定想要更新的镜像的 container.name，就是 nginx。
  

快速回滚

• 回滚的时候，其实是创建了 3 个旧版本的 pod，而并非把先前的 3 个 pod 恢复。
• 发布会新建replicaSet，回滚不会

DeploymentStatus

• Processing 指的是 Deployment 正在处于扩容和发布中。Processing 状态的 deployment，它所有的 replicas 及 Pod 副本全部达到最新版本，而且是 available，这样的话，就可以进入 complete 状态。而 complete 状态如果发生了一些扩缩容的话，也会进入 processing 这个处理工作状态。

Deployment和ReplicaSet的关系

Deployment控制器

• 原理：所有的控制器都是通过 Informer 中的 Event 做一些 Handler 和 Watch。这个地方 Deployment 控制器，其实是关注 Deployment 和 ReplicaSet 中的 event，收到事件后会加入到队列中。而 Deployment controller 从队列中取出来之后，它的逻辑会判断 Check Paused，这个 Paused 其实是 Deployment 是否需要新的发布，如果 Paused 设置为 true 的话，就表示这个 Deployment 只会做一个数量上的维持，不会做新的发布。
  • Check paused 为 Yes 也就是 true 的话，那么只会做 Sync replicas。也就是说把 replicas sync 同步到对应的 ReplicaSet 中，最后再 Update Deployment status，那么 controller 这一次的 ReplicaSet 就结束了。
  • paused 为 false 的话，它就会做 Rollout，也就是通过 Create 或者是 Rolling 的方式来做更新，更新的方式其实也是通过 Create/Update/Delete 这种 ReplicaSet 来做实现的。

ReplicaSet控制器

• 当 Deployment 分配 ReplicaSet 之后，ReplicaSet 控制器本身也是从 Informer 中 watch 一些事件，这些事件包含了 ReplicaSet 和 Pod 的事件。从队列中取出之后，ReplicaSet controller 的逻辑很简单，就只管理副本数。也就是说如果 controller 发现 replicas 比 Pod 数量大的话，就会扩容，而如果发现实际数量超过期望数量的话，就会删除 Pod。

spec字段解析

• MinReadySeconds：Deployment 会根据 Pod ready 来看 Pod 是否可用，但是如果设置了 MinReadySeconds 之后，比如设置为 30 秒，那 Deployment 就一定会等到 Pod ready 超过 30 秒之后才认为 Pod 是 available 的。Pod available 的前提条件是 Pod ready，但是 ready 的 Pod 不一定是 available 的，它一定要超过 MinReadySeconds 之后，才会判断为 available；
• revisionHistoryLimit：保留历史 revision，即保留历史 ReplicaSet 的数量，默认值为 10 个。这里可以设置为一个或两个，如果回滚可能性比较大的话，可以设置数量超过 10；
• paused：paused 是标识，Deployment 只做数量维持，不做新的发布，这里在 Debug 场景可能会用到；
• progressDeadlineSeconds：前面提到当 Deployment 处于扩容或者发布状态时，它的 condition 会处于一个 processing 的状态，processing 可以设置一个超时时间。如果超过超时时间还处于 processing，那么 controller 将认为这个 Pod 会进入 failed 的状态。

升级策略字段

• Deployment 在 RollingUpdate 中主要提供了两个策略，一个是 MaxUnavailable，另一个是 MaxSurge。这两个字段解析的意思，可以看下图中详细的 comment，或者简单解释一下：
  • MaxUnavailable：滚动过程中最多有多少个 Pod 不可用；
  • MaxSurge：滚动过程中最多存在多少个 Pod 超过预期 replicas 数量。
• 比如当用户的资源足够，且更注重发布过程中的可用性，可设置 MaxUnavailable 较小、MaxSurge 较大。但如果用户的资源比较紧张，可以设置 MaxSurge 较小，甚至设置为 0，这里要注意的是 MaxSurge 和 MaxUnavailable 不能同时为 0。
  • 两者同时为 0 的话，MaxSurge 保证不能新扩 Pod，而 MaxUnavailable 不能保证 ReplicaSet 中有 Pod 是 available 的，这样就会产生问题。所以说这两个值不能同时为 0。用户可以根据自己的实际场景来设置对应的、合适的值。

自测题目

https://gitchat.csdn.net/columnTopic/5d75e21809afba1228a0522c

通过 Deployment 不能实现以下功能：（单选题）C

• A. 应用扩缩容
• B. 应用发布回滚
• C. 应用重启
• D. 应用副本数量维持

一个 Deployment 中，哪些 labels/selector 必须一致：（单选题）C

• A. deployment.Labels 与 deployment.Spec.Template.Labels一致
• B. deployment.Labels 与 deployment.Spec.Selector 一致
• C. deployment.Spec.Selector 与 deployment.Spec.Template.Labels 一致
• D. deployment.Labels、deployment.Spec.Selector、deployment.Spec.Template.Labels 三者都要一致

创建 Deployment 描述文件中写的 template，用处不包括：（单选题）D

• A. 声明 Pod 的挂载目录
• B. 计算 ReplicaSet 的 hash
• C. 指定镜像版本
• D. 指定期望数量

以下哪个明显不是 deployment 扩容出来的 pod name ？（单选题）B

• A. nginx-deployment-77964d65f-5h52m
• B. nginx-deployment-676cc869
• C. nginx-deployment-6987cdb55b-r4tnr
• D. nginx-deployment-5c689d88bb-vqf4b

以下关于 revision 历史版本说法正确的是：（单选题）B

• A. 使用 deployment 可以 rollout 回滚到任何一个历史上的版本
• B. pod-template-hash 标识了 pod 的 revision 版本
• C. revisionHistoryLimit 字段不设置默认没有数量限制
• D. 更新了 deployment 任意字段，最新 revision 会发生变化

以下关于 paused 说法错误的是：（单选题）D

• A. 可以在 deployment 发布的过程中修改 paused 字段
• B. paused 默认值为 false
• C. paused 不可以用来暂停扩缩容操作
• D. deployment controller 在发布出现问题时会自动设置 paused

关于 MaxUnavailable 以下说法正确的是：（单选题）B

• A. MaxUnavailable 不可以设置为 0，否则无法发布 （可以设置为0，必须删除旧的，创建新的）
• B. MaxUnavailable 可以设置超过 replicas
• C. MaxUnavailable 可以和 MaxSurge 同时设置为 0 （不可以同时为0）
• D. MaxUnavailable 可以设置超过 100% （升级更新的字段，最多100%）

Deployment 与 ReplicaSet 的关系与以下哪组资源最像？（单选题）C

• A. Pod 与 Node
• B. Pod 与 Container
• C. ReplicaSet 与 Pod
• D. Deployment 与 Pod

指定 Deployment 回滚到某个历史版本执行成功的过程中，不会发生以下哪些事件：（多选题）BC

• A. Pod 创建和销毁
• B. ReplicaSet 创建和销毁
• C. Deployment 期望数量变化
• D. Deployment template 变化

以下关于 Deployment 的说法正确的有哪些?（多选题）AC

• A. Deployment 下 running 的 Pod 数量可能大于 replicas 数量
• B. Deployment 更新镜像时一定会创建一个 ReplicaSet
• C. Deployment 回滚时会创建一个 ReplicaSet
• D. 滚动发布的时候 MaxUnavailable 和 MaxSurge 可以同时设为 0