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

1、背景问题：

应用中的 Pod 如果出现了一些故障，如何保证集群内可用 Pod 的数量？

如何为所有 Pod 更新镜像版本？

在更新过程中，如何保证服务的可用性？

更新过程中，如果发现了问题，如何快速回滚到上一个版本？

2、Deployment 功能：

① Deployment 定义了 Pod 期望数量，比如说应用 A 期望 Pod 数量是四个，controller 就会持续维持 Pod 数量为期望的数量。当 Pod 出现问题时，controller 能进行恢复，保证可用的 Pod 数量与期望数量一致；

② 配置 Pod 发布方式，也就是说 controller 会按照用户给定的策略来更新 Pod，而且更新过程中，也可以设定不可用 Pod 数量在多少范围内；

③ 如果更新过程中发生问题的话，可以“一键”回滚，也就是通过一条命令或者一行修改，够将 Deployment 下面所有 Pod 更新为某一个旧版本 。

3、Deployment 语法：

① apiVersion：apps/v1 是说 Deployment 当前所属的组是 apps，版本是 v1。

② metadata 是 Deployment 的元信息。

③ Deployment.spec 中首先要有一个核心的字段 replicas，定义期望的 Pod 数量。

④ selector 是 Pod 选择器，它的 Labels 必须匹配 metadata 的 image.labels，也就是 app.nginx。

⑤ template 包含了两部分内容：

● 一部分是期望 Pod 的 metadata，其中包含了 labels；

● 第二部分是 Pod.spec，是 Deployment 最终创建出来 Pod 的时候所用的容器的规范。

4、查看 Deployment 状态：

(1) 可以通过 kubectl get deployment 查看 Deployment 总体的一个状态。

(2) 更新镜像：

kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1

(3) 快速回滚：

通过 kubectl rollout undo 这个命令，可以回滚到 Deployment 上一版本；

通过“rollout undo”加上“to-revision”来指定可以回滚到某一个具体的版本。

二、DeploymeStatus

deploymentStatus 中描述的三个其实是它的 conversion 状态，也就是 Processing、Complete 以及 Failed。

① Processing 指的是 Deployment 正在处于扩容和发布中。如果在 Processing 状态的 deployment 它所有的 replicas 及 Pod 副本全部达到最新版本，而且是 available的话，就可以进入 complete 状态。

② complete 状态如果发生了扩缩容的话，也会进入 processing 这个处理工作状态。

③ 如果在处理过程中遇到一些问题：比如拉镜像失败了，或者说 readiness probe 检查失败了，就会进入 failed 状态；进入 failed 状态之后，除非所有的 replicas 均变成 available，而且是 updated 最新版本，deployment 才会重新进入 complete 状态。

三、架构设计

1、管理模式

Deployment 只负责管理不同版本的 ReplicaSet，由 ReplicaSet 来管理具体的 Pod 副本数，每个 ReplicaSet 对应 Deployment template 的一个版本。

每一次修改 template，都会生成一个新的 ReplicaSet，这个 ReplicaSet 底下的 Pod 其实都是相同的版本。

2、扩/缩容模拟

有一个 Deployment，它的副本数是 2，对应的 ReplicaSet 有 Pod1 和 Pod2。如果修改 Deployment replicas， controller 就会把 replicas 同步到当前版本的 ReplicaSet 中，这个 ReplicaSet 发现当前有 2 个 Pod，不满足当前期望 3 个，就会创建一个新的 Pod3。

3、发布模拟

Deployment 当前初始为 template1 个版本。template1 这个 ReplicaSet 对应的版本下有三个 Pod：Pod1，Pod2，Pod3。

如果修改 template 中一个容器的 image， Deployment controller 就会新建一个对应 template2 的 ReplicaSet。创建出来之后 ReplicaSet 会逐渐修改两个 ReplicaSet 的数量，比如它会逐渐增加 ReplicaSet2 中 replicas 的期望数量，从而逐渐减少 ReplicaSet1 中的 Pod 数量。

最终达到的效果是：新版本的 Pod 为 Pod4、Pod5和Pod6，旧版本的 Pod 已经被删除了。

4、回滚模拟

根据上面的发布模拟可以知道 Pod4、Pod5、Pod6 已经发布完成。如果发现当前的业务版本是有问题的，可以回滚为旧版本的 template1。

Deployment 会重新修改 ReplicaSet1 中 Pod 的期望数量，把期望数量修改为 3 个，且会逐渐减少新版本也就是 ReplicaSet2 中的 replica 数量，最终的效果就是把 Pod 从旧版本重新创建出来。

初始版本中 Pod1、Pod2、Pod3 是旧版本，而回滚之后其实是 Pod7、Pod8、Pod9。就是说它的回滚并不是把之前的 Pod 重新找出来，而是重新创建出符合旧版本 template 的 Pod。