测验：GitOps 与持续交付

在使用 kustomize 覆盖的存储库中检查图像标签策略时，我应该瞄准什么？

• 使用 kustomize 构建渲染的结果。因为这就是进入集群的内容
• 基本目录中的原始清单。因为它是所有叠加的起点。
• 仅包含在提交差异中的行。这是因为当您只看到发生变化的内容时，检查速度会更快。
• 上传到注册表的图像列表。因为真正的神器就在那里

如果您在管道中运行策略工具并且存在违规行为，则构建将亮起绿灯。你应该先解决什么问题？

• 提高策略的严重性，使其在日志中更加突出
• 通过更严格地编写策略规则来捕获更多违规行为
• 将检查结果移至非零退出代码并使用该代码停止管道。
• 将检查阶段移至部署后，根据实际情况做出决策

在操作清单中将图像固定为摘要而不是标签的主要原因是什么？

• 这是因为摘要拉取图像的速度比标签快。
• 这是因为使用摘要可以让您跳过注册表身份验证。
• 这是因为标签有长度限制，不能包含所有版本信息。
• 这是因为标签可以再次推送，所以验证的内容和分发的内容可能会有所不同。

如果金丝雀策略的步骤设置为setWeight 10，然后立即设置为setWeight 100，会有什么问题？

• 权重之间没有停顿，因此没有判断的余地，导致满量程分布稍慢。
• 权重之和变为 110，因此 Rollout 控制器拒绝清单。
• 第一阶段 10% 的流量进入稳定版本，没有观察到金丝雀
• 不允许使用值 100，因此应始终省略最后一步。

检查不允许同时写入两个版本的分类帐服务上的蓝色/绿色。正确的设计条件是什么？

• 将金丝雀权重降低到 1% 可以消除对同一账本的并发写入
• 单独控制预览版本的写入并验证数据兼容性和过渡程序
• 将 autoPromotionEnabled 设置为 false 还会阻止写入文件的预览版本。
• 写入RWO时，之前的版本会自动终止，因此不需要写入器控制。

您输入了 Rollout 的 prePromotionAnalysis 引用的 AnalysisTemplate 的名称。什么时候会揭晓呢？

• 当您应用清单时，架构验证会检查并拒绝引用。
• 当 Rollout 控制器启动时，所有引用都会被预先解释并作为事件通知。
• 只有当您尝试运行促销前分析时，这一点才会变得明显。因此，您在分发之前需要单独检查。
• 分析被悄悄视为成功，直到最后才揭晓。

创建 Argo CD 应用程序时将 spec.project 保留为默认值有哪些风险？

• 默认项目不支持自动同步，因此只能手动同步。
• 对于属于默认项目的应用程序，修剪选项将被忽略。
• 默认项目无法自动创建命名空间，导致第一次同步失败。
• 默认项目允许任何存储库、集群和任何资源类型。

Argo CD同步显示成功，但目标命名空间中没有任何内容。您将首先对比哪两个值？

• 应用程序的destination.namespace和渲染结果的metadata.namespace
• 应用程序的 targetRevision 和存储库的默认分支名称
• Application的项目名称和AppProject的sourceRepos列表
• 应用程序中的syncPolicy.automated 和控制器中的重试计数