测验：连同配置一起重现的恢复

尽管我更改了 ConfigMap 中的 HEALTHY 值，但使用 envFrom 的现有 pod 的响应保持不变。您应该首先考虑哪种解释？

• 此修复不会自动更新正在运行的容器中的环境变量。
• 由于ConfigMap中的数据始终是不可变的，因此修改请求将被无条件忽略。
• 部署会自动将所有外部配置更改恢复为其之前的值。
• 阻止服务将新的环境变量传递给健康的 Pod。

以前的部署修订版也引用相同的设置 ConfigMap 名称。如果我推出撤消操作并留下设置错误消息怎么办？

• Pod 模板和外部 ConfigMap 数据在同一时间点一起恢复。
• 恢复到之前的 Pod 模板，但不保证恢复外部设置
• 如果 ConfigMap 名称相同，即使没有以前的修订，设置也会恢复。
• 删除先前版本中使用的所有外部对象并重新创建它们。

一个新 Pod 的就绪响应是 503，但服务是 200。我还需要查看什么才能确定新版本部署是否成功？

• 检查服务地址是否与变更前相同，如果相同则确定部署完成。
• 进行另一个 HTTP 调用，如果为 200，则跳过新的副本状态。
• 将响应 pod 的所有权关系与当前模板的更新/就绪副本进行比较。
• 检查 API apply 命令是否成功并忽略准备新 Pod 失败

对于具有 2 个副本的 maxSurge=1 和 maxUnavailable=0 示例，最准确的解释是什么？

• 在任何情况下，当前运行的所有 pod 中都必须有 2 个。
• 即使新的 Pod 还没有准备好，现有的 Pod 也必须立即一一删除。
• 通过此设置，即使在节点故障或配置错误的情况下也能保证不间断运行。
• 限制部署以维持现有可用容量，直到新 Pod 准备就绪

对settings-v1应用immutable=true后，数据修改被拒绝。这个结果直接证明了什么？

• 要点是对对象配置数据的更改会被拒绝。
• 没有权限删除和重新创建该对象。
• 关键是同一个名字将永远拥有同一个 UID。
• 里面的值是加密的，可以安全地秘密存储。

在使用特定于版本的不可变设置的部署中，需要保留哪些内容才能恢复到以前的版本？

• 只要记住之前设置的名称，就可以整理内容了。
• 保留以前的模板及其引用的设置。
• 只记录当前服务的ClusterIP，并清除所有旧设置。
• 将旧名称添加到新配置中，以便引用名称相同。

在测试回滚后替换单个健康 Pod 的私有虚拟机时，是否有强有力的恢复持久性证据？

• 删除前保存的正常响应仍保留在文件中。
• 替换后的 pod 与之前的 pod 具有相同的名称前缀
• 具有新UID的Pod读取之前的设置并通过ready/HTTP验证。
• 跳过查找自己的团队 Pod，因为其他团队 Pod 正常

推出观察命令达到了 10 秒的限制，但尚未查看控制器的最终裁决。正确的下一步行动是什么？

• 由于确认安装失败，再次运行相同的安装命令。
• 由于仅关闭了观察窗口，因此恢复被记录为完成，无需额外确认。
• 创建一个具有相同名称的新部署并连接现有观察。
• 通过查询同一执行的状态、条件和 Pod 响应来区分不完整和失败。