1. GitOps 理念与核心原则
1.1 GitOps 定义
GitOps 是一种以 Git 仓库作为声明式基础设施和应用程序的单一事实来源的运维模式。它通过自动化同步机制，确保集群的实际状态始终与 Git 仓库中定义的期望状态保持一致。GitOps 将 Git 的操作流程（分支、合并、回滚、审批）直接映射到生产环境的变更管理上，使整个交付过程可审计、可复现、可回滚。
核心公式： GitOps = 声明式配置 + Git 版本控制 + 自动化同步
1.2 声明式与命令式对比
理解 GitOps 必须先区分两种配置管理范式：声明式（Declarative）与命令式（Imperative）。
| 维度 | 命令式（Imperative） | 声明式（Declarative） |
|---|---|---|
| 操作方式 | 执行具体指令（kubectl run、kubectl scale） | 描述期望状态（YAML 清单） |
| 状态管理 | 手动跟踪当前状态，逐步执行操作 | 系统自动调和，持续逼近期望状态 |
| 可复现性 | 依赖操作顺序和上下文，难以复现 | 配置即代码，任意时刻可复现 |
| 审计能力 | 操作日志分散，难以追溯 | Git 历史完整记录每次变更 |
| 回滚方式 | 手动执行反向操作，易出错 | Git revert 或 reset，自动同步回滚 |
| 典型工具 | kubectl 命令、Shell 脚本 | Flux、Argo CD、Kustomize、Helm |
实践建议： 在 GitOps 工作流中，应完全避免使用 kubectl 命令直接修改集群状态。所有变更必须通过 Git 仓库的 Pull Request 发起。
1.3 Git 作为单一事实来源
在 GitOps 模型中，Git 仓库不仅是代码存储库，更是整个系统的真理源。这意味着：
- 期望状态唯一性： 集群中所有资源的期望状态都定义在 Git 仓库中，不存在任何游离于 Git 之外的配置。
- 变更全链路可追溯： 每一次配置变更都对应一个 Git commit，包含变更人、时间、原因和代码差异。
- 分支策略即环境策略： 通常使用 main 分支对应生产环境，feature 分支对应开发环境，通过合并操作完成环境晋升。
- 不可变基础设施： 任何环境差异都通过 Git 分支或目录结构体现，避免配置漂移。
1.4 自动化同步机制
自动化同步是 GitOps 的执行引擎。它持续监控 Git 仓库中的期望状态与集群实际状态之间的差异，并自动执行调和操作。Flux 作为 CNCF 毕业的 GitOps 工具，其同步机制包含以下关键环节：
- 源监控（Source Monitoring）： Flux 定期轮询 Git 仓库（或 Helm 仓库、OCI 制品库），检测是否有新的 commit 或 tag。
- 配置拉取（Config Pull）： 检测到变更后，Flux 从仓库拉取最新的清单文件到本地缓存。
- 差异计算（Diff Calculation）： Flux 将拉取的期望状态与集群当前状态进行对比，生成差异清单。
- 自动调和（Auto Reconciliation）： 根据差异清单，Flux 自动创建、更新或删除 Kubernetes 资源，使集群状态趋近于期望状态。
- 状态反馈（Status Feedback）： Flux 将调和结果写回 Git 仓库（可选），或通过事件、指标暴露同步状态。
注意： 自动化同步并不意味着无限制的自动变更。生产环境中应结合 Pull Request 审批 和 渐进式交付（如 Flagger）来控制变更风险。Flux 支持配置同步策略（如：仅同步特定分支、路径或标签），避免意外覆盖。
1.5 GitOps 核心原则总结
根据 Weaveworks 和 CNCF 社区的定义，GitOps 包含以下五项核心原则：
- 声明式配置： 整个系统由声明式描述定义，而非命令式指令。
- 版本控制与不可变性： 所有配置存储在 Git 中，每次变更产生新的版本，历史不可篡改。
- 自动拉取期望状态： 系统自动从 Git 拉取期望状态，无需手动触发部署。
- 持续调和： 系统持续对比实际状态与期望状态，自动修复漂移。
- 闭环反馈： 同步结果、健康状态和告警信息反馈给运维人员，形成闭环。
关键认知： GitOps 不是 CI/CD 的替代品，而是对 CD 环节的重新定义。CI（持续集成）仍然在 GitOps 之外运行，负责构建镜像和生成制品；GitOps 接管的是 CD（持续交付/部署）阶段，确保制品以声明式方式部署到目标环境。