测验：Application 与同步

同一个 sync wave 中有 Service 和 Deployment。它们的应用顺序由什么决定？

• 同一文件中清单的书写顺序，即 YAML 文档的出现顺序
• 没有固定规则，控制器按捕获到资源的先后顺序并行应用
• 按 kustomization.yaml 的 resources 中所列文件名的字典序
• 按资源类型规定的默认顺序（Namespace、ConfigMap、Service、工作负载）

未指定 argocd.argoproj.io/hook-delete-policy 时，其默认值和效果是什么？

• HookSucceeded — 钩子 Job 成功结束后立即删除该资源
• BeforeHookCreation — 保留钩子资源，直到下一次 sync 即将创建新钩子时才将其删除
• HookFailed — 仅在钩子 Job 失败时删除，成功时则保留
• 不存在默认策略，因此在明确指定删除策略前根本不会执行钩子

为什么 syncPolicy.automated.prune: true 特别危险？

• 因为 prune 不仅会删除应用创建的资源，还会把容纳这些资源的命名空间整个删除
• 因为重建 prune 所删除资源的过程中，所有 Pod 会同时重启，从而造成瞬时停机
• 因为启用 prune 后不会保留以前的修订记录，无法通过 argocd app rollback 回滚
• 因为只要有一次提交把 source.path 指向错误位置，导致渲染结果为 0，该应用管理的所有资源都会成为删除目标

selfHeal: true 的作用是什么？

• 将在仓库中删除的资源也从集群中删除
• 当集群实际状态与仓库不一致时，将其恢复为仓库中定义的状态
• 找到健康检查失败的 Pod 并自动重启
• 按照固定间隔自动重试失败的同步

将 AppProject 的 sourceRepos 设为 ["*"] 会带来什么问题？

• 任何仓库都可以用于部署，使通过项目划分边界失去意义
• repo-server 无法固定仓库列表，因此无法使用清单缓存
• 通配符不是有效值，会在创建 Application 时被拒绝
• 每次都必须扫描完整的允许列表，导致同步速度明显变慢

对于由 HPA 管理的 Deployment，ArgoCD 不断重复 Syncing。最恰当的措施是什么？

• 使用 ignoreDifferences 将 /spec/replicas 排除在比较范围之外
• 关闭此 Application 的自动同步，仅在需要时手动同步
• 删除 HPA，并在仓库中为 replicas 写入固定值以固定副本数
• 增大 retry.limit，让反复同步最终收敛到同一个值

为什么要为 retry.backoff 设置 factor？

• 为了限制单个钩子 Job 可以占用的最长执行时间
• 为了逐渐拉长重试间隔，避免失败的同步以相同间隔持续请求 API 服务器
• 为了增加在规定时间内可以进行的重试次数
• 为了在多个应用同时失败时规定重试顺序