测验：配置交付与服务恢复的证据

新的 Git 修订版与 Synced·Healthy 匹配，但工作路径为 500。对此观察结果有何解释？

• 由于控制器同步的成功和任务请求的成功是分开的，因此请调查设置和响应。
• Healthy 检查所有 HTTP 路径，因此它首先清除用户的浏览器缓存。
• 同步只能在以前的提交上进行，因此请手动初始化状态字段
• 500表示DNS解析失败，所以不考察正常的应用设置。

更改ConfigMap后，现有subPath挂载上的nginx继续显示500。最直接的下一项研究是什么？

• 清除整个 Argo CD 缓存并重新启动所有应用程序控制器。
• 通过比较 API 设置、Pod 中的文件和 Pod UID 来检查消耗边界。
• 当前设置已更新，因此报告因外部支付系统故障而关闭。
• 强制远程 main 到先前的提交并销毁更改历史记录

我们想要声明当配置哈希更改时将创建一个新的 Pod。该方法中的注释应该放在哪里？

• 仅将metadata.annotations放在ConfigMap中以使kubelet创建一个新的Pod
• 直接更新Ready，将其放入Deployment的status.conditions中
• 通过将模板放置在 Deployment 的 spec.template.metadata.annotations 中来更改模板。
• 通过将文件放置在应用程序的metadata.labels 中，可以在执行期间直接替换文件。

配置提交后，我部署了模板提交。哪种组合最适合作为 Git 恢复的证据？

• 只有应用程序名称和Healthy颜色相同，但不记录commit和Pod身份。
• 如果 ConfigMap 主体是新值，则不会进一步调查来自先前 Pod 的 500 个响应。
• 如果只是新Pod的名称不同，则省略响应体以及是否替换Deployment。
• 比较提交沿袭·同步修订版·新Pod UID·挂载文件·200主体

VM 上的 ClusterIP 工作路径 3 次返回 200。运营报告的适当结论是什么？

• 内部路线的观察样本是成功的，但需要对外部路线和持续可用性进行额外检查。
• 由于外部DNS和TLS在同一个集群中，因此无需单独观察即可确认正常。
• 由于我们取得了三个成功，我们计算出我们已经达到了每月的可用性目标。
• 由于是Pod Ready，所以不区分成功体是否是旧版本。

部分创建的 rollout.json 就位后，我单击“准备”以执行上一步。帮助者的正确行为是什么？

• 为了减少学习时间，当前步骤将被答案文件覆盖。
• 保留现有文件，仅准备不存在的先前步骤，并且不创建当前答案。
• 删除现有文件后，像正常观察一样通过使用 JSON 修饰的所有步骤。
• 每次你删除并重新评分现有的观察结果时，你都会从头开始重新制造同样的混乱。