1. GitOps概述
GitOps 是一种以 Git 仓库作为单一事实来源（Single Source of Truth）的声明式运维与交付模式。它将 Git 的工作流（分支、合并、回滚、审计）直接映射到基础设施与应用的变更管理上，使整个发布过程可版本化、可审计、可自动化。
1.1.1 GitOps 定义
GitOps 由 Weaveworks 在 2017 年正式提出，其核心思想是：用 Git 仓库中的声明式描述文件（YAML/JSON）定义整个系统的期望状态，并通过自动化控制器持续将实际集群状态向期望状态收敛。任何对系统的修改都必须先提交到 Git，再由 Operator 或 CI/CD 管道应用到目标环境。
关键公式： GitOps = 声明式基础设施 + 版本控制 + 自动化同步 + 可观测性
1.1.2 核心原则
| 原则 | 说明 | 实践体现 |
|---|---|---|
| 声明式描述 | 系统期望状态以声明式文件定义，而非命令式脚本 | Kubernetes YAML、Terraform HCL、Crossplane Composition |
| 版本化与不可变 | 所有变更通过 Git commit 记录，每次部署对应一个确定版本 | Git 提交 SHA、Tag、Release 分支 |
| 自动同步 | 控制器持续对比 Git 期望状态与集群实际状态，自动修复偏差 | Argo CD 的 Auto-Sync、Flux 的 Reconciliation |
| 可审计与回滚 | 每次变更都有完整历史，回滚只需 revert 一次 Git 提交 | Git revert、git bisect、审计日志 |
1.1.3 与传统 CI/CD 的区别
| 维度 | 传统 CI/CD | GitOps |
|---|---|---|
| 触发方式 | CI 管道构建镜像 → CD 工具推送部署 | Git 仓库变更 → 控制器自动同步 |
| 状态管理 | CD 工具内部数据库或状态文件 | Git 仓库作为唯一事实来源 |
| 漂移修复 | 通常需要手动干预或额外脚本 | 控制器自动检测并回滚到期望状态 |
| 权限模型 | CI/CD 工具拥有集群凭据 | Git 仓库权限控制变更入口，Operator 只读同步 |
| 回滚复杂度 | 需找到历史版本并重新触发部署 | git revert 一次提交即可 |
实践建议： 传统 CI/CD 适合“构建与测试”阶段，GitOps 更适合“部署与运维”阶段。两者可以互补：CI 负责构建镜像并更新 Git 仓库中的部署清单，GitOps 负责将清单同步到集群。
1.1.4 GitOps 的四大支柱
GitOps 架构建立在四个核心支柱之上，它们共同构成了从代码提交到生产环境稳定运行的完整闭环：
- 声明式系统（Declarative System） — 所有基础设施、应用配置、策略都以声明式文件描述，不依赖命令式脚本或手动操作。
- 版本控制与不可变存储（Versioned & Immutable Storage） — Git 仓库存储所有期望状态，每次变更产生不可变的版本快照，支持审计、追溯和回滚。
- 自动同步控制器（Automated Sync Controller） — 运行在目标集群中的 Operator 持续拉取 Git 仓库中的期望状态，并与集群实际状态对比，自动修复偏差。
- 可观测性与反馈（Observability & Feedback） — 控制器暴露同步状态、健康检查、事件告警，运维人员可通过 Dashboard 或 Webhook 实时了解集群状态。
1.1.5 GitOps 工作流全景
下图展示了从开发者提交代码到生产环境自动同步的完整 GitOps 工作流，包含 CI 构建、Git 仓库更新、控制器同步三个关键阶段：
常见误区： GitOps 不等于“把 YAML 文件放到 Git 里”。如果没有自动同步控制器和漂移修复机制，仅仅将配置文件存储在 Git 中仍然是传统运维模式，无法享受 GitOps 带来的自愈和审计优势。
1.1.6 本章小结
- GitOps 以 Git 仓库为单一事实来源，通过声明式描述和自动同步实现基础设施与应用的可控发布。
- 四大核心原则：声明式描述、版本化不可变、自动同步、可审计回滚。
- 与传统 CI/CD 的关键区别在于状态管理方式、漂移修复机制和权限模型。
- 四大支柱（声明式系统、版本控制、自动同步控制器、可观测性）构成了 GitOps 的完整技术栈。