1. GitOps 概述：定义、核心原则与传统 CI/CD 的区别
GitOps 是一种以 Git 仓库作为单一事实来源（Single Source of Truth）的运维与交付模式。它将声明式配置、版本控制与自动化部署相结合，使整个应用交付生命周期可审计、可回滚、可复现。本节从定义出发，逐步拆解其核心原则，并与传统 CI/CD 模式进行对比。
1.1 GitOps 的定义
GitOps 由 Weaveworks 在 2017 年正式提出，其核心思想是：用 Git 仓库管理所有环境（开发、测试、预发布、生产）的期望状态，并通过自动化控制器持续将实际状态收敛到期望状态。任何对基础设施或应用配置的变更，都必须通过 Pull Request（PR）提交到 Git 仓库，由自动化流水线或 Operator 完成同步。
关键公式： GitOps = 声明式配置 + 版本控制 + 自动化同步 + 自愈机制
1.2 核心原则
GitOps 建立在以下四条不可动摇的原则之上：
| 原则 | 说明 | 实践体现 |
|---|---|---|
| 声明式（Declarative） | 系统期望状态由配置文件完整描述，而非通过命令式脚本逐步执行 | Kubernetes YAML、Terraform HCL、Crossplane Composition |
| 版本控制（Version Controlled） | 所有配置变更必须通过 Git 提交，形成不可篡改的审计轨迹 | Git 提交记录、PR 审批、标签与分支策略 |
| 自动化（Automated） | 从 Git 到运行环境的同步过程完全自动化，无需人工 SSH 或 kubectl | Argo CD、Flux、Jenkins X 自动同步 |
| 自愈（Self-Healing） | 当实际状态偏离期望状态时，系统自动纠正，无需人工介入 | Kubernetes 控制器、Operator 循环调和 |
实践提示： 声明式是 GitOps 的基石。如果团队仍在使用命令式脚本（如
kubectl run 或 ssh 手动修改配置），则无法真正落地 GitOps。
1.3 GitOps 核心工作流
下图展示了 GitOps 从代码提交到环境同步的完整闭环：
1.4 与传统 CI/CD 的区别
传统 CI/CD 与 GitOps 在架构、安全模型、部署策略上存在本质差异。下表从多个维度进行对比：
| 对比维度 | 传统 CI/CD | GitOps |
|---|---|---|
| 配置管理 | 命令式脚本 + 手动操作 | 声明式 YAML / HCL 文件 |
| 真相源 | CI/CD 工具数据库 + 人工记忆 | Git 仓库（唯一真相源） |
| 部署触发 | CI 构建完成后自动推送 | Git 仓库配置变更触发同步 |
| 回滚方式 | 重新运行旧版本流水线或手动恢复 | git revert 回退提交，Operator 自动同步 |
| 环境一致性 | 依赖流水线脚本，易产生漂移 | 所有环境配置版本化，天然一致 |
| 安全模型 | CI/CD 工具需要集群凭证 | Operator 通过 Git 凭证拉取，无需集群级权限 |
| 自愈能力 | 无，需人工巡检 | 内置自愈循环，自动纠正漂移 |
| 审计追踪 | 分散在 CI/CD 日志中 | Git 提交历史即完整审计日志 |
常见误区： GitOps 不是“用 Git 存 CI/CD 脚本”，而是“用 Git 存环境的期望状态”。如果团队只是把 Jenkinsfile 或 GitLab CI 配置放到 Git 里，但部署仍然通过 CI 工具直接推送，那仍然是传统 CI/CD，不是 GitOps。
1.5 传统 CI/CD 与 GitOps 架构对比
下图从架构层面直观展示两种模式的差异：
1.6 何时选择 GitOps
GitOps 并非银弹，以下场景最适合引入 GitOps：
- 多环境管理：开发、测试、预发布、生产环境配置需要严格版本控制与一致性。
- 合规与审计要求高：金融、医疗等行业需要完整的变更审计轨迹。
- 团队规模增长：多人协作时，PR 审批流程可有效减少误操作。
- Kubernetes 为主的技术栈：K8s 的声明式 API 与 GitOps 天然契合。
- 需要自愈能力：生产环境需要自动纠正配置漂移，减少人工介入。
一句话总结： GitOps 将 Git 工作流（分支、PR、Code Review）延伸到运维领域，让基础设施管理像管理应用代码一样严谨、可追溯、可自动化。