背景问题
-
如何保证集群内可用 Pod 数量
- 运行期间宿主机故障
- 更新时，需要停止之前的节点
-
为所有 Pod 更新镜像
replicaset好像可以，它和Deployment的区别是？
-
更新过程中，发现问题如何回滚已更新的节点
Deployment：管理部署发布的控制器
每个 Deployment 管理的一组相同的应用 Pod （副本）
-
Controller 会维持 Pod 达到期望的数量
-
配置 Pod 发布方式，Controller 会按照给定策略更新 Pod，保证更新过程中不可用的 Pod 数量在一定范围内，控制滚动更新
-
支持“一键”回滚
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}-${random-suffix}
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 数量。
