测验：部署完成与回滚的边界

新模板是 v3，availableReplicas=2，服务响应是 v2。最准确的判断是什么？

• 现有 v2 的可用性可能会保持，因此请进一步检查 UpdatedReplicas·Condition·Response。
• 由于有两个可用副本，因此确定v3部署完成，仅缓存响应版本。
• 由于服务交付了 v2，部署控制器确定它已自动回滚。
• 现在 API 已收到模板，将服务选择器更改为直接指向 v3。

仅更改了 Deployment 对象的注释，spec.template 保持不变。哪一个比较最能说明这一变化的影响？

• 比较注解发生变化的时间以及节点CPU利用率是否同时增加。
• 比较现有的ReplicaSet·Pod UID和修订版本是否被维护
• 比较当注释值作为环境变量注入时应用程序响应是否发生变化。
• 由于API响应成功，请比较是否已收到新的图像摘要。

环境变量 COLOR 在 ConfigMap 中注入为蓝色的 Pod 正在运行。仅将ConfigMap更改为绿色时可以观察到什么？

• ConfigMap 保持蓝色，控制器仅将 Pod 的环境变量更改为绿色。
• 仅当 Pod 使用相同的 UID 自动重启时，ConfigMap 更改请求才会成功。
• ConfigMap 为绿色，但现有进程的响应仍为蓝色。
• 将创建一个新的 ReplicaSet，并立即删除所有现有的 Pod。

2 个副本，maxSurge=1，maxUnavailable=0，新 Pod 未准备就绪。这个实验中可能出现哪些状态？

• 由于总共必须有 2 个 Pod，因此请立即删除 1 个旧 Pod 以腾出空间。
• 由于有新的 Pod，两个现有的健康 Pod 都被排除在转发之外。
• 忽略新 Pod 准备失败并将所有三个 Pod 视为可用。
• 仍保留两个现有的正常 Pod 和一个新的、未准备好的 Pod。

进度=False，原因=ProgressDeadlineExceeded。以下哪项陈述是正确的？

• 这是表示进度失败的情况，恢复是通过查看所需的模板和实际响应来确定的。
• 这意味着它已自动回滚到正常版本，因此请跳过检查历史记录或模板。
• 这意味着容器活性失败，因此必须增加重新启动的次数。
• 这意味着整个集群已经终止，因此所有命名空间都被重新创建。

ConfigMap 是紫色的，正常的 v2 进程保持绿色。从 v3 部署回滚到 v2 失败后，我还应该检查什么？

• 由于回滚会恢复所有外部状态，因此它只记录 ConfigMap 之前的资源版本。
• 检查ConfigMap是否保持紫色，并检查对下次Pod创建的影响。
• 如果当前响应为绿色，则推断新创建的 Pod 也是绿色的。
• 即使 v2 正常，ConfigMap 也会被删除，因此应用程序会继续使用现有值。

手动回滚到普通版本 2 后，当前 Deployment 版本为 4，现有的普通 v2 Pod 仍然保留。我们该如何解读呢？

• 由于当前数字不是2，我们假设回滚命令没有被执行。
• 由于 Pod UID 已被维护，我们假设声明没有发生更改。
• 这是一个新的更改，它恢复到以前的模板并比较实际的模板/副本/响应。
• 由于版本号增加，因此假设应用程序代码也必须是 v4。

自我修复在单独的 GitOps 操作环境中打开。如果手动回滚后 Git 中仍然有失败的声明怎么办？

• 一旦手动命令成功，Git声明会自动修改为正常版本。
• 如果当前Pod是健康的，Git和集群之间的差异不会影响以后的调整。
• 为了维持回滚，所有控制器和就绪检查必须永久关闭
• 所需的恢复状态必须反映在 Git 中，并且必须再次检查实际的推出/响应。