跟 k8s 工作负载 Deployments 的缘起缘灭
考点之简略介绍一下什么是 Deployments 吧？考点之怎么查看 Deployment 上线状态？考点之集群中能不能设置多个 Deployments 控制器具备重叠的标签选择器？考点之能够自定义 Pod-template-hash 标签嘛？如果能够，有什么益处？如果不能够，有什么危害？考点之什么场景下会触发 Deployments 上线动作？考点之 Deployments 在更新时会敞开所有 Pod 嘛？如果不是，默认敞开最大比例是多少？考点之你能不能简略形容一下 Deployments 更新时 RS 和 Pod 是如何滚动更新的？考点之如何断定 Deployment 上线过程是否呈现停滞？有哪些起因会造成停滞？如何解决配额有余的问题？考点之保留订正历史会耗费 etcd 中的资源，并占用 `kubectl get rs` 的输入，如果给订正历史限度值设置为 0 是不是就能无效解决这个问题？
囧么肥事 - 胡言乱语
考点之简略介绍一下什么是 Deployments 吧？
Deployments是 k8s 内置的工作负载之一，次要作用是帮忙咱们治理 无状态 Pod。
一个 Deployment 为 Pods 和 ReplicaSets 提供了申明式的更新能力，咱们只须要负责形容 Deployment 中的 RS 和 Pod 须要达到的指标状态，那么 DM 就会以一种受控速率去帮忙咱们更改 RS 和 Pod 的理论状态，使其变为咱们冀望呈现的状态。
Deployment 很适宜用来治理你的集群上的 无状态利用，Deployment 认为所有的 Pod 都是互相等价的，在须要的时候都是能够替换的。
Deployment: "小 Pod 们，都给我听话"
DM: "你们都不是惟一的"
DM: "不听话，闹事的 Pod"
DM: "随时能够让你走人"
DM: "大把的 Pod 能够替换你们"
Pods: "是是是，咱们肯定听话"Deployment 是一个实干主义者，你如果好好工作，不闹事，那么所有 OK，然而如果你有小心理，敢闹事，那它随时能够赶你走人，随时随地能够招新人。
考点之怎么查看 Deployment 上线状态？
Deployment 的生命周期中会有许多状态。上线新的 ReplicaSet 期间可能处于Progressing（进行中），可能是 Complete（已实现），也可能是Failed（失败）进入阻塞停滞无奈持续进行。
利用kubectl rollout status 命令能够监督 Deployment 的进度。
假如创立了一个 Nginx 的 DM，查看 DM 进度。
kubectl rollout status deployment/nginx-deployment哪些场景会让 Deployment 进入这三种状态呢？
为了不便，后续 DM 均代表 Deployment
进行中（Progressing）
当 Deployment 执行上面的工作期间，Kubernetes 将其标记为 进行中（Progressing）：
- DM 创立新的 `ReplicaSet`
- DM 正在为最新的 `ReplicaSet` 执行扩容操作
- DM 正在为旧的 `ReplicaSet` 执行缩容操作
- 新的 Pods 曾经就绪或者可用（就绪至多继续了 `MinReadySeconds` 秒）实现（Complete）
当 Deployment 具备以下特色时，Kubernetes 将其标记为 实现（Complete）：
- 与 DM 关联的所有正本都已更新到指定的最新版本，这意味着之前申请的所有更新都已实现。- 与 DM 关联的所有正本都可用。- 未运行 DM 的旧正本。失败的（Failed）
当Deployment 在尝试部署其最新的 ReplicaSet 受挫时，会始终处于未实现状态。造成此状况可能因素如下：
- 配额（Quota）有余
- 就绪探测（Readiness Probe）失败
- 镜像拉取谬误
- 权限有余
- 限度范畴（Limit Ranges）问题
- 利用程序运行时的配置谬误考点之集群中能不能设置多个 Deployments 控制器具备重叠的标签选择器？
首先答案必定是不能的。
如果这样做，结果是什么呢？如果有多个控制器的标签选择器产生重叠，则控制器之间会因抵触而无奈失常工作。
另一篇曾经探讨相似问题：线上预警 k8s 集群循环创立、删除 Pod 正本，始终无奈稳固指定指标正本数量? 如果排除了是 Pod 外部产生了故障，从 RS 角度你猜想可能是什么起因？
上一篇次要阐明的是多个 ReplicaSets 配置了雷同的标签选择符，应用雷同的标签选择器创立多个ReplicaSet，则多个 RS 无奈辨认哪个 Pod 是本人创立的，都会认为是归属于本人治理的 Pod。这样做的结果就是会造成 Pod 被竞争接管的状况，导致 Pod 正本数量始终无奈稳固。
咱们晓得 Deployment 为 Pods 和 ReplicaSets 提供了申明式的更新能力，次要管控的是 RS 和 Pods。
Kubernetes 不会阻止你去给设置重叠的标签选择器，然而既然 RS 和 Pods 会呈现因为竞争克服引发的 治理抵触 状况，那么身为他们俩的管理者 DM 必定是不能独善其身，肯定会受到影响的。
那么为了不呈现 治理抵触，咱们应该怎么做呢？
必须在 Deployment 中指定适当的标签选择器和 Pod 模板标签，同时标签或者标签选择器不要与其余控制器（包含其余 Deployment 和 StatefulSet）重叠。
考点之能够自定义 Pod-template-hash 标签嘛？如果能够，有什么益处？如果不能够，有什么危害？
k8s 官网阐明：不要更改此标签
k8s 官网间接明确的通知咱们，不要自定义 Pod-template-hash 标签， 那么为什么呢？凭什么就不能自定义？
Deployment 控制器会将本人创立或者治理的每一个 ReplicaSet 身上都 标注 Pod-template-hash 标签。
惟一的目标就是利用这个标签 确保 Deployment 的子 ReplicaSets 不重叠。
留神 Deployment 中 ReplicaSet 的名称始终 被格式化 为[Deployment 名称]-[随机字符串]。
其中随机字符串是应用 pod-template-hash 作为种子随机生成的。
通过对 ReplicaSet 的 PodTemplate 进行哈希解决，所生成的哈希值被增加到 ReplicaSet 的标签选择器、Pod 模板标签，以及 RS 中的每个 Pod 身上。
疑难来了，自定义有什么危害呢？
下面说了，这个标签次要是作为名称随机，确保不重叠，随机到每一个 Pod 和 RS 上，能够避免出现多个 Deployments 控制器具备重叠的标签选择器。也就是下面说的那个竞争排挤问题。
考点之什么场景下会触发 Deployments 上线动作？
仅当 Deployment Pod 模板（即 .spec.template）产生扭转时，例如 模板的标签或容器镜像被更新，才会触发 Deployment 上线。
其余更新（如对 Deployment 执行扩缩容的操作）不会触发上线动作。
考点之 Deployments 在更新时会敞开所有 Pod 嘛？如果不是，默认敞开最大比例是多少？
Deployment 可确保在更新时仅敞开肯定数量的 Pod。
默认状况下，它确保至多所需 Pods 75% 处于运行状态（maxUnavailable最大不可用比例为 25%）。
如果有 100 个 Pod，在更新时，最多敞开 25 个 Pod
DM 保障至多会有 75 个 Pod 能失常提供服务Deployment 还确保所创立 Pod 数量只可能比冀望 Pods 数高一点点。
默认状况下，它可确保启动的 Pod 个数比冀望个数 最多多出 25%（最大峰值 25%）。
DM 更新会呈现两种操作
1、销毁老版本 Pod
2、创立新版本 Pod
无论是销毁还是创立
默认峰值都是 25%
销毁时，最多同时销毁 25%Pod
保障有 75% 的 Pod 能够持续提供服务
创立时，最多运行比预期正本数多出 25%
也就是说如果预期存活 Pod 正本是 100 个
那么最多容许同时在运行 125 个旧版正本 + 新版正本考点之你能不能简略形容一下 Deployments 更新时 RS 和 Pod 是如何滚动更新的？
如果不去更改默认的最大不可用比例和最大运行峰值比例，那么 DM 更新时，会创立新版本 RS，并将其进行扩容，管制到 Pod 正本数量 满足最大运行峰值比例。
达到比例后，DM 会进行新版 RS 扩容，不会再创立新版 Pod，直到 DM 杀死足够多的旧版 Pod
接下来对旧版本 RS 进行缩容操作，管制去除 Pod 正本数量 满足最大不可用比例。
同样，达到比例后，DM 会进行旧版 RS 删除，不会再持续删除旧版 Pod，直到 DM 创立到足够多的新版 Pod
此为一轮更新，DM 一直的进行滚动更新上述操作，直到旧版 RS，旧版 Pod 正本数为 0，新版正本数稳固，进行滚动更新。
考点之如何断定 Deployment 上线过程是否呈现停滞？有哪些起因会造成停滞？如何解决配额有余的问题？
Deployment 可能会在尝试部署最新的 ReplicaSet 时呈现故障，始终处于未实现的停滞状态。
造成此状况 一些可能因素 如下：
- 配额（Quota）有余
- 就绪探测（Readiness Probe）失败
- 镜像拉取谬误
- 权限有余
- 限度范畴（Limit Ranges）问题
- 利用程序运行时的配置谬误如何断定 Deployment 上线过程是否呈现停滞？
检测此情况的一种办法是在 Deployment 规约中 指定截止工夫 参数.spec.progressDeadlineSeconds。
一旦超过 Deployment 进度限期，Kubernetes 将更新 DM 状态和进度情况的起因：
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing False ProgressDeadlineExceeded
ReplicaFailure True FailedCreate通过 Deployment 状态，就能晓得是否呈现停滞。你能够应用 kubectl rollout status 查看 Deployment 是否未能获得停顿。如果 Deployment 已超过进度限期，kubectl rollout status 返回非零退出代码。
判断停滞，这时候咱们能够在 上线过程两头平安地暂停 Deployment，对其进行上线修复。
假如排查出停滞起因是配额有余，间接在命名空间中增 加配额 来解决配额有余 的问题。
配额条件满足，Deployment 控制器实现了 Deployment 上线操作，Deployment 状态会更新为胜利情况（Status=True and Reason=NewReplicaSetAvailable）
考点之保留订正历史会耗费 etcd 中的资源，并占用 kubectl get rs 的输入，如果给订正历史限度值设置为 0 是不是就能无效解决这个问题？
.spec.revisionHistoryLimit 是一个可选字段，用来设定为回滚操作所备份保留的旧 ReplicaSet 数量。
这些旧 ReplicaSet 会耗费 etcd 中的资源，并占用 kubectl get rs 的输入。
每个 Deployment 订正版本的配置都存储在其 ReplicaSets 中；
因而，一旦删除了旧的 ReplicaSet，将失去回滚到 Deployment 的对应订正版本的能力。
默认状况下，零碎保留 10 个旧 ReplicaSet，但其现实值取决于新 Deployment 的频率和稳定性。
如果给订正历史限度值设置为 0，将导致 Deployment 的所有历史记录被清空。没有了历史备份，因而 Deployment 将无奈回滚，无奈吊销新的 Deployment 上线。
总结：尽管能够缩小 etcd 的资源耗费，然而 不利于 k8s 集群实现故障容错、高可用。为了节约一些资源，而放弃容错，高可用性质，只能说，十分十分十分，不值得。