1. GitOps 基础概念
1.1 什么是 GitOps
GitOps 是一种以 Git 仓库作为单一事实来源（Single Source of Truth）的运维与交付模式。它将声明式配置、版本控制与自动化交付管道相结合，使基础设施和应用的变更全部通过 Git 提交来驱动，而非手动执行命令或脚本。
核心思想： 任何对生产环境的修改，必须先修改 Git 仓库中的声明式描述文件，再由自动化工具（如 Argo CD、Flux）将变更同步到目标集群。Git 仓库的状态即环境的期望状态。
GitOps 的典型工作流包含以下环节：
- 开发/运维人员 修改 Git 仓库中的 YAML/JSON 声明文件并提交 PR。
- CI 管道 执行校验、测试、镜像构建，合并至主分支。
- GitOps Operator 检测到 Git 仓库状态变化，自动拉取最新配置。
- Operator 将声明式配置与集群当前状态进行比对（Reconciliation）。
- Operator 自动执行变更，使集群状态收敛至 Git 中定义的期望状态。
1.2 声明式模型与命令式模型的区别
理解声明式与命令式的差异是掌握 GitOps 的前提。两种模型在操作方式、可审计性、幂等性等方面存在本质区别。
| 对比维度 | 命令式模型（Imperative） | 声明式模型（Declarative） |
|---|---|---|
| 操作方式 | 执行具体命令：kubectl run、kubectl scale |
提交期望状态文件：kubectl apply -f deploy.yaml |
| 状态管理 | 由操作者手动跟踪当前状态 | 系统自动比对并收敛至期望状态 |
| 幂等性 | 非幂等，重复执行可能产生不同结果 | 幂等，重复 apply 结果一致 |
| 审计与回滚 | 依赖操作日志，难以精确回滚 | Git 历史即审计轨迹，可精确回滚至任意版本 |
| 适用场景 | 临时调试、快速验证、一次性操作 | 生产环境、持续交付、合规审计 |
| 典型工具 | kubectl 命令、Shell 脚本 |
Argo CD、Flux、Terraform、Pulumi |
实践建议： 在 GitOps 工作流中，应完全避免使用命令式操作修改生产环境。即使临时调试，也应通过 Git 提交声明式变更来驱动，确保所有变更可追溯。
1.3 GitOps 的核心原则
GitOps 并非单一工具，而是一套架构原则。CNCF 定义的 GitOps 核心原则包含以下五点：
- 声明式描述 —— 整个系统的期望状态必须通过声明式配置文件（YAML、JSON、HCL 等）完整描述，而非通过命令序列。
- 版本控制与不可变性 —— 所有声明式配置存储在 Git 中，每次变更产生新的提交，历史版本不可篡改。
- 自动拉取（Pull-based） —— Operator 主动从 Git 仓库拉取配置并与当前状态比对，而非由 CI/CD 推送至集群。
- 持续 Reconciliation（状态收敛） —— Operator 持续运行控制循环，确保集群实际状态始终与 Git 中的期望状态一致。
- 可观测与可审计 —— 所有变更通过 Git 提交记录、PR 审批、CI 结果形成完整审计链，集群状态差异可实时监控。
常见误区： 很多团队将 Git 仅用作代码仓库，仍通过 CI 推送（Push-based）方式部署。这不符合 GitOps 的 Pull-based 原则，会导致集群状态与 Git 仓库状态不一致，丧失 GitOps 的核心优势。
1.4 声明式模型在 GitOps 中的实践价值
声明式模型为 GitOps 带来了以下关键能力：
- 配置即代码（CaC） —— 所有环境配置以代码形式管理，可进行 Code Review、静态分析、单元测试。
- 环境一致性 —— 开发、预发、生产环境使用同一套声明式模板，仅参数不同，消除环境漂移。
- 自动修复 —— 当集群状态因故障或手动操作偏离期望状态时，Operator 自动将其修复回 Git 定义的状态。
- 多集群管理 —— 通过 Git 仓库中的目录结构或 Kustomize overlay 管理数十甚至数百个集群的配置。