1. GitOps 基础概念
1.1 什么是 GitOps
GitOps 是一种以 Git 仓库作为单一事实来源（Single Source of Truth）的云原生交付与运维模式。它将声明式配置、版本控制、自动化同步和可观测性融合在一起，使基础设施和应用交付像管理代码一样可审计、可回滚、可协作。
核心思想： 所有环境状态（Kubernetes 资源、配置、策略）都存储在 Git 中，通过自动化工具（如 Argo CD、Flux）持续将 Git 中的期望状态同步到目标集群。
1.2 声明式交付
声明式交付（Declarative Delivery）是指用户描述期望的最终状态，而非编写一步步的操作指令。系统负责计算并执行从当前状态到期望状态的转换路径。
| 对比维度 | 声明式（Declarative） | 指令式（Imperative） |
|---|---|---|
| 用户关注点 | “系统应该是什么样子” | “系统应该怎么做” |
| 配置形式 | YAML / JSON 清单文件 | kubectl run / create / delete 命令 |
| 幂等性 | 天然幂等，重复执行结果一致 | 非幂等，需人工判断状态 |
| 回滚方式 | Git revert → 自动同步 | 手动执行反向操作 |
| 典型工具 | kubectl apply -f, Argo CD, Flux | kubectl run, helm install --set |
实践要点： 声明式交付要求所有资源清单都存储在 Git 中，且每次变更都通过 PR/MR 提交。避免在集群上直接执行 kubectl run 或 kubectl edit 等指令式操作，否则会导致 Git 与集群状态不一致（配置漂移）。
1.3 Git 作为单一事实来源
在 GitOps 模型中，Git 仓库是唯一被信任的期望状态定义。集群中运行的所有资源都必须与 Git 中的声明式配置完全一致。任何手动修改集群的行为都被视为“配置漂移”，GitOps Operator 会自动将其纠正回 Git 中定义的状态。
- 不可变历史： Git 的 commit 历史记录了每一次变更的完整上下文，包括谁、什么时间、为什么修改。
- 审计合规： 所有环境变更都有迹可循，满足 SOC2、PCI-DSS 等合规要求。
- 灾难恢复： 集群完全损坏时，只需在新集群上部署 GitOps Operator，即可从 Git 恢复全部资源。
- 多环境一致性： 开发、测试、生产环境使用同一套 Git 仓库，通过 overlay 或 kustomize 差异化配置。
1.4 GitOps vs 传统 CI/CD
传统 CI/CD 以流水线（Pipeline）为中心，强调构建、测试、部署的自动化流程；GitOps 则以Git 仓库为中心，强调状态声明和持续同步。两者并非互斥，而是互补关系。
| 对比维度 | 传统 CI/CD | GitOps |
|---|---|---|
| 驱动方式 | 事件驱动（代码 push → 触发流水线） | 状态驱动（Git 变更 → 自动同步期望状态） |
| 部署方式 | 流水线 push 制品到目标环境 | Operator pull Git 配置并 apply 到集群 |
| 配置漂移 | 不检测，手动修改后无自动纠正 | 持续检测并自动纠正回 Git 状态 |
| 回滚操作 | 重新运行旧版本流水线或手动回滚 | Git revert → 自动同步回滚 |
| 权限模型 | CI 系统拥有集群凭证，权限较大 | Operator 拥有集群凭证，开发者仅需 Git 权限 |
| 适用场景 | 构建、测试、镜像打包、静态分析 | 环境部署、配置管理、策略下发 |
常见误区： 不要试图用 GitOps 完全替代 CI。CI 负责构建和测试，GitOps 负责部署和配置管理。正确的做法是：CI 流水线将构建产物（如容器镜像）推送到镜像仓库，然后更新 Git 仓库中的部署清单（如修改镜像 tag），GitOps Operator 检测到 Git 变更后自动同步到集群。
1.5 GitOps 典型工作流
- 开发者提交代码 到应用代码仓库，触发 CI 流水线。
- CI 流水线 执行构建、单元测试、安全扫描，生成容器镜像并推送到镜像仓库。
- CI 更新配置仓库：将新镜像 tag 写入 GitOps 配置仓库中的部署清单（如 deployment.yaml）。
- GitOps Operator（如 Argo CD）检测到配置仓库变更，拉取最新清单。
- Operator 对比差异：将 Git 中的期望状态与集群当前状态进行 diff。
- 自动同步：Operator 执行 kubectl apply 将集群状态调整为 Git 中定义的期望状态。
- 持续监控：Operator 持续监控集群状态，发现漂移立即纠正。
关键收益： 开发者无需直接操作集群，所有变更都通过 Git 进行，实现“Git 即部署开关”。配合 PR Review 机制，每次环境变更都经过代码审查，大幅降低误操作风险。