GitOps 与 Argo CD 实践指南
GitOps 的核心不是“安装 Argo CD”，而是把期望状态放入 Git，通过审查、自动对比和受控同步，让集群变更可追溯、可复现。Git 是事实来源，但生产安全还依赖权限、密钥、测试和回退设计。
一、基本工作流
提交变更 -> 合并请求审查 -> 自动测试 -> Git 中期望状态更新
-> Argo CD 比较差异 -> 手动或自动同步 -> 健康检查与观测
应用代码仓库和环境配置仓库可分开。镜像构建流水线不必直接拿集群管理员权限；它只更新受控配置，Argo CD 在集群侧完成拉取和同步。
二、仓库建议
environments/
dev/
test/
prod/
apps/
service-a/
base/
overlays/
platform/
ingress/
observability/
目录应清楚表达应用、环境和责任边界。生产配置变更需代码审查和保护分支；镜像标签应使用不可变版本或摘要，不建议直接跟随 latest。
三、先从手动同步开始
初次落地时，建议让 Argo CD 只显示差异，由人工确认同步。稳定后再逐步启用自动同步、自愈和清理。
spec:
syncPolicy:
automated:
enabled: true
prune: false
selfHeal: false
prune 会删除 Git 中已移除的资源，selfHeal 会覆盖集群中的手工变更。两者都应在资源归属、保护策略和回退经过验证后再启用。不要在初次试用时同时开启所有自动能力。
四、密钥与权限
- Git 仓库、集群凭据和应用密钥分开管理。
- Argo CD 项目限制允许的仓库、集群、命名空间和资源类型。
- SSO 与 RBAC 遵循最小权限，默认角色不要给予全局同步或删除能力。
- Secret 不应以明文提交到 Git，可使用受控密钥系统或加密方案。
- 对高风险资源启用审批、同步窗口和删除保护。
五、发布顺序与健康检查
CRD、控制器、配置、数据库迁移和应用往往有先后关系。可通过 Sync Phase、Wave 与 Hook 控制顺序，但 Hook 失败后的处理必须明确。
健康状态不能只依赖 Pod Running。应用应提供 Readiness、关键依赖检测和业务探针，并在发布后观察错误率、延迟和资源使用。
六、回退的正确理解
Git 回退是再提交一个恢复期望状态的变更，并不自动撤销数据库写入或不可逆迁移。发布设计应区分：
- 可通过重新部署旧镜像恢复的应用变更；
- 需要向前修复的数据库 Schema；
- 已删除数据或外部资源；
- 自动同步期间发生的并行修改。
生产回退应提前演练，并记录配置、镜像和数据的恢复边界。
七、常见误区
- 允许管理员长期直接修改集群，导致 Git 与运行状态反复漂移。
- 一个 Argo CD 管理所有环境却没有项目、权限和网络边界。
- 自动清理前没有识别共享资源和手工维护资源。
- 把 Git 中 Secret 加密后就忽略了解密密钥、日志和缓存泄露。
- 只看同步成功，不看应用是否真正可用。
八、验收清单
- 任意生产变更都能追溯到提交、审查人和发布记录。
- 手工漂移能被发现，处理方式有明确规则。
- 项目、仓库、集群和命名空间权限符合最小权限。
- 同步失败、健康异常和长时间 OutOfSync 有告警。
- 自动清理和自愈经过非生产演练。
- 应用、配置和数据回退边界已记录。