1. GitOps 基础概念
GitOps 是一套以 Git 仓库作为单一事实来源（Single Source of Truth）的云原生部署与运维模式。它将声明式配置、版本控制与自动化协调器结合，使基础设施和应用的变更可审计、可回滚、可复现。本节从定义、声明式部署、与 CI/CD 的差异以及核心原则四个维度建立 GitOps 的理论基础。
1.1 GitOps 定义
GitOps 由 Weaveworks 在 2017 年正式提出，其核心思想是：将整个系统的期望状态声明在 Git 仓库中，并通过一个自动化 Operator（如 Argo CD、Flux）持续将集群实际状态向 Git 中的期望状态对齐。任何对系统的修改都必须先修改 Git 仓库中的声明文件，再由 Operator 自动或手动同步到目标环境。
关键区别：传统运维中，Git 仅作为代码存储；GitOps 中，Git 是运维操作的唯一入口和状态权威。
1.2 声明式部署
声明式部署（Declarative Deployment）是 GitOps 的基石。与命令式（Imperative）方式不同，声明式部署只描述“系统应该是什么状态”，而不描述“如何达到该状态”。Kubernetes 原生支持声明式 API，用户通过 YAML/JSON 清单定义资源的期望状态，由控制器负责调和。
| 维度 | 命令式部署 | 声明式部署 |
|---|---|---|
| 操作方式 | 执行具体命令（kubectl run、kubectl scale） | 提交清单文件（kubectl apply -f） |
| 状态管理 | 状态分散在命令历史中 | 状态集中在 Git 仓库 |
| 可审计性 | 弱，依赖操作者记录 | 强，每次变更都有 Git commit |
| 回滚方式 | 手动逆向操作 | git revert 或切换分支 |
| 典型工具 | kubectl run/delete/edit | kubectl apply、Helm、Kustomize |
实践要点：在 GitOps 工作流中，禁止直接使用
kubectl run 或 kubectl edit 修改集群状态。所有变更必须通过 Git 仓库的 Pull Request 流程进行。
1.3 GitOps 与 CI/CD 的区别
传统 CI/CD 管道通常将 CI（持续集成）和 CD（持续部署）视为一个连续流程：CI 构建镜像，CD 将镜像部署到环境。GitOps 则对 CD 阶段进行了根本性重构——CD 不再是一个“推送”过程，而是一个“拉取”过程。
| 对比维度 | 传统 CI/CD | GitOps 模式 |
|---|---|---|
| 部署触发 | CI 管道完成后直接推送至集群 | CI 更新 Git 仓库，Operator 拉取同步 |
| 部署方向 | 推送（Push） | 拉取（Pull） |
| 状态权威 | CI/CD 系统状态 | Git 仓库 |
| 安全模型 | CI 系统需要集群凭证 | Operator 持有凭证，CI 无需直接访问集群 |
| 回滚能力 | 依赖 CI/CD 系统历史 | Git 原生回滚，简单可靠 |
| 环境一致性 | 环境间配置易漂移 | 所有环境从 Git 同步，配置一致 |
常见误区：GitOps 并不取代 CI。CI 仍然负责代码编译、测试、镜像构建与推送。GitOps 改变的是 CD 阶段的部署模型——CI 将更新后的清单推送到 Git 仓库，而不是直接推送到集群。
1.4 GitOps 核心原则
根据 CNCF GitOps Working Group 的定义，GitOps 有四项核心原则。这些原则是评估一个工具或实践是否符合 GitOps 模式的标准。
- 声明式描述：整个系统的期望状态必须通过声明式配置（Kubernetes 清单、Helm Chart、Kustomize 等）完整描述。
- 不可变且可版本化的期望状态：所有声明式配置存储在 Git 中，每次变更产生新的 commit，支持版本对比、审计和回滚。
- 自动拉取期望状态：集群中运行的软件代理（Operator）自动从 Git 拉取期望状态，并与实际状态进行调和。
- 持续调和与偏差纠正：Operator 持续监控集群实际状态，一旦发现与 Git 期望状态不一致，自动执行纠正操作。