六、应用编排与管理： Deployment

背景问题

1. 如何保证集群内可用 Pod 数量
   1. 运行期间宿主机故障
   2. 更新时，需要停止之前的节点
2. 为所有 Pod 更新镜像 replicaset好像可以，它和Deployment的区别是？
3. 更新过程中，发现问题如何回滚已更新的节点

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

每个 Deployment 管理的一组相同的应用 Pod （副本）

1. Controller 会维持 Pod 达到期望的数量
2. 配置 Pod 发布方式，Controller 会按照给定策略更新 Pod，保证更新过程中不可用的 Pod 数量在一定范围内，控制滚动更新
3. 支持“一键”回滚 annotation 里会保存上一次 kubectl 操作的资源的 json 的描述，不知道和这个有关系没 试验了下，annotation只保存上一次的，而回滚可以回退多个版本，可知没关系

Deployment 语法

查看 Deployment 状态

命令：kubectl get deployment

发现个事，kubectl get查看资源时，单复数都可以，例如 pod & pods

• DESIRED：期望的 Pod 数量是 3 个；
• CURRENT：当前实际 Pod 数量是 3 个；
• UP-TO-DATE：其实是到达最新的期望版本的 Pod 数量；
• AVAILABLE：这个其实是运行过程中可用的 Pod 数量。后面会提到，这里 AVAILABLE 并不简单是可用的，也就是 Ready 状态的，它其实包含了一些可用超过一定时间长度的 Pod；
• AGE：deployment 创建的时长，如上图 Deployment 就是已经创建了 80 分钟。

Pod 名字

通过 deployment 创建的 Pod ，名字格式为：{deployment-name}-{template-hash}-

ownerReferences

• 所有者为 replicaset 创建 deployment 时也会创建 replicaset，这个流程是？ 所有的 Pod 都是 ReplicaSet 创建出来的，而 ReplicaSet 它对应的某一个具体的 Deployment.template 版本。
• 名字为 {deployment-name}-{template-hash}

更新镜像

• deployment.v1.apps：资源名.资源版本.资源组
• 资源版本：非必填，默认v1
• 资源组：非必填，默认apps
• nginx=nginx:1.16.1：前面个nginx是容器名

回滚

• 查看历史版本

• 回滚到指定版本

• 不加版本就是会退到上一个版本
• 默认保存10份历史版本，可通过deployment.spec.revisionHistoryLimit修改

架构设计

管理模式

• Deployment 只负责管理不同版本的 ReplicaSet，由 ReplicaSet 来管理具体的 Pod 副本数
• 每个 ReplicaSet 对应 Deployment template 的一个版本，每一次修改 template，都会生成一个新的 ReplicaSet
• 一个 ReplicaSet 底下的 Pod 其实都是相同的版本
• 职责拆分，Deployment 负责版本控制，ReplicaSet 负责控制副本数量

Deployment 控制器

• Deployment 控制器关注的是 Deployment 和 ReplicaSet 中的 event
• Paused：Deployment 是否需要新的发布，如果 Paused 设置为 true 的话，就表示这个 Deployment 只会做一个数量上的维持，不会做新的发布
• 这里应该也是循环控制模式，先对 replicatset CUD，再监听到 replicatset 的事件，然后更新 deployment 的状态

ReplicaSet 控制器

• 不只监听 replicaaset 事件，还监听了 pod 事件。除了 deployment 产生的 replicatset事件，还可能因为其他原因，pod 数量变化了，也会触发 replicaset 控制器调整副本数量。
• 这里也是循环控制模式，replicaset 调整 pod 数量，pod 数量变更触发 replicaset 更新status

发布模拟

• 注意滚动更新的细节，宏观上是 pod 的替换，微观上是控制两个 replicaset 的 replicas 。具体值和升级策略有关

Deployment spec 字段解析

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

升级策略

Deployment 在 RollingUpdate 中主要提供了两个策略

• MaxUnavailable：滚动过程中最多有多少个 Pod 不可用；
• MaxSurge：滚动过程中最多存在多少个 Pod 超过预期 replicas 数量。