用 Argo CD 实践 GitOps

让 Git 成为集群期望状态的唯一来源，并让变更过程可审计、可回滚。

图：环境仓固定制品摘要，控制器持续比较 Git 期望状态与集群实际状态；点击查看原图。

核心思路

将应用清单与环境差异分离，生产分支启用评审保护。Argo CD 负责比较和同步，镜像构建流水线只更新版本，不直接持有集群管理员权限。

落地步骤

自动同步适合成熟服务；数据库迁移和高风险变更可保留人工窗口。告警应覆盖同步失败、健康异常和持续漂移。

验证清单

实施后不要只确认“能运行”，还应检查错误率、延迟、资源占用和异常路径。把验证命令、预期结果和回滚方式写进变更记录，后续维护会轻松很多。

小结

好的工程实践不是堆叠工具，而是用清晰边界、可观察结果和可逆变更降低长期成本。先解决最重要的问题，再逐步自动化。

可执行实践

仓库保存期望状态，CI 只构建镜像并更新不可变版本，Argo CD 负责差异与同步。为生产项目限制可用仓库、目标 namespace 和集群资源类型。

验证与退出条件

先在手动同步模式观察 diff，再逐步开启自动同步与 self-heal。对于数据库迁移和删除资源，保留审批窗口并监控持续漂移。

实践场景

以“让集群状态由受审查的仓库版本驱动”为例。实施前先保存当前版本、配置和关键指标基线，写明成功条件与停止条件；涉及生产数据或外部写入时，先在隔离环境验证。

分步实施

分离应用源码与部署声明，固定镜像摘要；为同步顺序、健康检查和敏感配置建立清晰边界。每完成一步都记录可观察结果，不把命令返回零等同于业务正确。

故障演练

手工修改集群资源制造漂移，再提交一个错误声明，确认系统能发现差异且不会绕过保护直接删除关键资源。演练应使用可清理的测试数据，并验证告警、日志和恢复路径，而不只是确认系统最终又能访问。

观测与回滚

观察 OutOfSync、Health 和同步耗时；故障时回退 Git 提交并让控制器重新收敛。变更单中应写清负责人、观察窗口、阈值和回滚触发器，避免故障发生后再临时争论。

完成后把使用的版本、关键命令、观测窗口和结果写入变更记录。没有验证证据的“已完成”不能作为上线结论。

第二轮实践复核

可复用交付物： 不可变部署声明、同步策略和回滚提交。复用时先固定软件版本、依赖锁文件、测试数据规模和运行环境；文章中的命令包含占位符，必须替换成自己的非生产目标后再执行。

最低验证： argocd app diff demo && argocd app get demo

执行记录要保存命令、退出码、关键输出、观察窗口和回滚结果。若验证会产生写入，先使用隔离环境或 dry-run；任何失败都不能通过扩大权限、关闭校验或跳过测试来“解决”。

完整实战：让 Git、集群和发布证据对齐

应用仓库产出带摘要的镜像，环境仓库只更新部署声明：

1
2
3

image:
  repository: registry.example.com/order-api
  digest: sha256:0123456789abcdef...

使用摘要而非 latest，让 Git 中的期望状态精确指向已扫描制品。自动化提交包含源提交、镜像摘要和验证结果；部署控制器只拥有目标 namespace 所需权限，不能让普通应用仓库间接修改集群级 RBAC。

同步策略按资源风险分层

资源	建议策略	原因
Deployment/Service	自动同步 + 健康检查	易回退、状态清晰
数据库迁移 Job	独立阶段、幂等、人工门禁	有数据副作用
CRD/RBAC	单独应用与审阅	影响范围大
删除共享资源	默认禁止自动 prune	恢复成本高

同步波次只能表达顺序，不能保证业务就绪。每个阶段要有真实健康条件；PreSync hook 重试时必须幂等，hook 完成记录不能是唯一审计证据。

漂移、回滚与紧急修改

故意手改一个低风险副本数，确认控制器能报告 drift，并按策略纠正。生产紧急修改若无法等待 Git 流程，要记录操作者、原因和时限，随后立即回写 Git；否则下一次 reconcile 会覆盖现场修改。

回滚通过环境仓库提交把摘要恢复到上一已验证版本。若新版本执行了不兼容数据迁移，单纯回滚清单不会恢复数据，因此迁移应采用 expand/contract 并独立验证。观察 sync 状态、health、reconcile 时长、漂移数、hook 失败和应用 SLO；控制器异常时先暂停自动化副作用，保留 Git 与集群证据，不要循环点击强制同步。

一手资料

资料与版本边界复核日期：2026-08-22。工具行为可能演进，实施前以锁定版本对应的官方文档为准。