测验：发布与恢复的证据

新提交已同步，但 pod 未就绪且 HTTP 失败。最准确的解释是什么？

• 它可能与新声明一致，但服务准备情况和响应成功必须单独验证。
• 由于是同步的，HTTP 失败必然是客户端 DNS 问题
• 这意味着 Git 更改不会得到反映，因此它会继续推送相同的提交
• 如果容器正在运行，则部署决策中将排除就绪结果。

应用程序的 targetRevision 是健康提交 A 的完整 SHA。我们只将新提交 B 推送到分支 main。您可以期待什么行动？

• 如果自动同步打开，则始终转到 B
• 如果您继续跟踪 A 并想要部署 B，则还需要更新跟踪目标
• 分支移动后，A 就会从存储库中删除
• 当B到达时，Argo CD永久禁用自动同步

在好的 A 之后，我们 git 将坏的 B 恢复到新的提交 C。这种无状态配置恢复的正确验证是什么？

• 仅当 SHA 等于 A 时观察才成功
• 只需一条表明 C 被推送的日志就足够了
• 将 C 的更改与观察到的 SHA、就绪状态和实际响应进行比较。
• 如果C有消息revert，则跳过pod状态

新的 Pod 就绪失败，但服务请求不断达到 200。在 RollingUpdate 环境中我应该首先检查什么？

• Kubernetes 会忽略就绪失败吗？
• 如果响应为 200，则新版本中的所有 Pod 均正常。
• Git 会自动恢复图像标签吗？
• 以前健康的 Pod 是否保留在端点上来处理请求

即使 JSON 为空，部署授权功能也会成功。我应该添加什么验证？

• 如果缺少所需的证据，则拒绝，并测试反例，例如缺少字段、以前的提交和不正确的文本。
• 所有缺失的数字均被更正为 0 并处理为成功。
• 重新执行一次正常响应以增加通过次数
• 通过清除缺失字段的日志来减少用户的困惑

虚拟机向Service ClusterIP发送一个HTTP请求是正常的。这些证据的范围有多大？

• 我们已经验证了外部 DNS、TLS、身份验证和所有工作流程的成功。
• 请求和路由已确认成功，分别检查外部路由和其他工作流程。
• 展示了持续的 SLO 服务成就
• 在此版本中恢复数据库迁移是安全的