测验：漂移与 self-heal

在启用了 selfHeal: true 的应用中，通过 kubectl scale 增加了 replicas。接下来会怎样？

• 仓库会自动更新，并将新值保存为一次提交
• 该应用会一直保持 OutOfSync 状态
• 由于操作者不是所有者，scale 命令本身会被拒绝
• 在下一个调谐周期恢复为仓库中记录的值

prune 根据什么判断删除对象？

• 最后一次同步之后新建的所有对象
• 没有任何 GitOps 相关标签或注解的对象
• 标记为由此应用所有，但渲染后的清单中不存在的对象
• 位于 Application 所指定命名空间之外的对象

一个误将 source.path 改为空目录的提交已被合并，并且启用了 prune: true。最直接的防护措施是什么？

• 增大 revisionHistoryLimit，保留足够多可供回滚的修订版本
• 将 retry.limit 设为 0，避免反复执行错误同步
• 启用 CreateNamespace=true，让被删除的命名空间立即重建
• 通过 syncPolicy.automated.allowEmpty: false 拒绝空的渲染结果

某个 Application 同时处于 Synced 和 Degraded 状态。这意味着什么？

• 这表示仓库与集群的内容不一致
• 这表示应用尚未完成，同步仍在进行中
• 这两种状态不可能同时出现，因此属于显示错误
• 配置已按仓库的要求应用，但资源未正常运行

如果 diff 阶段没有通过规范化去除 resourceVersion、uid、managedFields、status，会怎样？

• 由于省去了预处理步骤，diff 计算反而会稍微加快
• 由于无法读取所有权标记，prune 会完全失效
• 即使没有改动，也会每次都报告差异并无限同步
• 同步阶段会被跳过，因此不会执行 sync hook

为什么在本实验环境中创建的 Application 不会自行变为 Synced？

• 因为 Application CRD 应用错误，schema 只注册了一半
• 因为此环境中没有运行 ArgoCD Application Controller
• 因为 Application 对象不在 argocd 命名空间中
• 因为所指向的仓库没有远程仓库，无法填充状态字段

对于生产环境的 Application，以下哪种常见折中方案最合适？

• 不区分环境，同时启用两者，让仓库与集群始终完全一致
• 同时关闭 prune 和 selfHeal，仅通过人工批准的手动同步进行部署
• 启用 selfHeal，但谨慎使用 prune 或保留手动同步，避免误合并的删除操作立即生效
• 只启用 prune 并关闭 selfHeal，在同步删除的同时保留手动修改的值