GitOps 工作流

要解决什么问题

Kubernetes 上若仍靠 kubectl apply 或 CI 里的一次性脚本推送变更，集群实际状态很容易与团队共识脱节：谁改了什么、能否回滚、多环境如何对齐，往往依赖口头约定和手工对账。GitOps 把期望状态放进 Git，由集群内的控制器持续拉取并对账，让部署变成可审计、可回滚的声明式流程。

技能如何组织内容

本技能围绕 OpenGitOps 四条原则（声明式、版本化不可变、自动拉取、持续同步），分别说明 ArgoCD 与 Flux CD 的落地路径：从仓库布局与 Application / GitRepository + Kustomization 建模，到自动同步、金丝雀与蓝绿等渐进式交付，以及 External Secrets、Sealed Secrets 等不把明文 Secret 写进 Git 的做法。流程上强调四步：约定仓库与期望状态 → 安装控制器并接入集群 → 配置同步策略与环境升级 → 验证回滚与 Secret 处理；并覆盖 App of Apps、多集群、RBAC、健康检查与同步失败告警等运维细节。

适用边界与注意点

适合需要为 K8s 建立长期 Git 驱动交付、多集群或渐进发布策略的团队；不适合只做一次性手工部署、无法管理集群或仓库权限、或目标根本不是 Kubernetes 的场景。安全上应避免对生产开启无审批的自动同步；生产变更宜配合审批门禁，并先在预发布环境验证同步与回滚。