1. GitOps 概述：定义、核心原则与传统 CI/CD 的区别
GitOps 是一种以 Git 仓库作为单一事实来源（Single Source of Truth）的运维与交付模式。它将声明式配置、版本控制与自动化部署流水线相结合，使基础设施和应用的变更管理完全可追溯、可审计、可回滚。本节从定义出发，逐步拆解其核心原则，并与传统 CI/CD 模式进行对比。
1.1 GitOps 定义
GitOps 由 Weaveworks 在 2017 年正式提出，其核心思想是：用 Git 仓库描述整个系统的期望状态，并通过自动化控制器持续将实际状态收敛到期望状态。在 Kubernetes 生态中，GitOps 通常表现为：
- 所有资源配置（Deployment、Service、ConfigMap 等）以 YAML 或 Helm Chart 形式存储在 Git 仓库中。
- 集群内运行一个 Operator（如 Argo CD、Flux），持续监听仓库变更。
- 当仓库发生提交时，Operator 自动将变更同步到集群；当集群状态偏离仓库定义时，Operator 自动修复。
关键理解： GitOps 不是一种工具，而是一种模式。Git 仓库既是配置中心，也是审计日志，更是回滚的锚点。
1.2 核心原则
GitOps 建立在三条不可分割的核心原则之上，三者缺一不可：
| 原则 | 说明 | K8s 中的体现 |
|---|---|---|
| 声明式（Declarative） | 系统状态由配置文件描述，而非通过命令式指令逐步构建。 | kubectl apply -f deployment.yaml 是声明式；kubectl run 是命令式。 |
| 版本控制（Version Controlled） | 所有配置变更必须通过 Git 提交，形成不可篡改的变更历史。 | 每次回滚对应一次 git revert 或 checkout 到历史 commit。 |
| 自动化（Automated） | 集群控制器自动检测期望状态与实际状态的偏差，并执行收敛。 | Argo CD 的 Auto-Sync 模式持续对比 Git 与集群状态。 |
实践提示： 声明式是 GitOps 的前提。如果团队仍在使用命令式脚本管理 K8s 资源，建议先迁移到 Helm/Kustomize 声明式配置，再引入 GitOps 流水线。
1.3 GitOps 与传统 CI/CD 的区别
传统 CI/CD 流水线（如 Jenkins、GitLab CI）通常将 CI 与 CD 视为一个连续过程：CI 构建镜像，CD 通过 kubectl 或 Helm 将镜像部署到集群。这种方式存在几个关键缺陷：
- 配置漂移： 手动 kubectl edit 或临时热修复会导致集群状态与仓库不一致。
- 回滚困难： 回滚需要重新触发流水线，且难以保证回滚后的状态与历史版本完全一致。
- 权限分散： 多人直接操作集群，缺乏统一的审计入口。
GitOps 通过将 CD 阶段从流水线中剥离，交给集群内的 Operator 完成，从根本上解决了上述问题。以下表格对比了两种模式的核心差异：
| 维度 | 传统 CI/CD | GitOps |
|---|---|---|
| 部署触发方式 | CI 流水线完成后，通过脚本或 API 调用部署 | Git 仓库提交触发 Operator 自动同步 |
| 状态来源 | 流水线参数或环境变量 | Git 仓库中的声明式配置文件 |
| 配置漂移检测 | 无内置机制，依赖人工巡检 | Operator 持续对比，自动修复偏差 |
| 回滚方式 | 重新运行旧版本流水线或手动 kubectl apply | git revert 或 checkout 到历史 commit，Operator 自动执行 |
| 审计与合规 | 依赖 CI 日志，可能不完整 | Git 提交记录即完整审计日志 |
| 多集群管理 | 需要为每个集群单独配置部署脚本 | 一个 Git 仓库可管理多个集群，通过目录或分支隔离 |
常见误区： GitOps 并不完全取代 CI。CI 阶段（代码编译、单元测试、镜像构建与推送）仍然在传统流水线中完成。GitOps 接管的是 CD 阶段——将镜像版本写入 Git 仓库后，由 Operator 完成部署。
1.4 GitOps 工作流全景
下图展示了 GitOps 模式下从代码提交到集群部署的完整闭环。CI 流水线负责构建镜像并更新 Git 仓库中的版本号，GitOps Operator 负责将仓库状态同步到 K8s 集群。
1.5 为什么 GitOps 更适合 K8s 回滚
在传统 CI/CD 模式中，回滚通常意味着重新运行一条旧的流水线，或者手动执行 kubectl rollout undo。这两种方式都存在状态不一致的风险：
- 重新运行流水线： 如果流水线依赖的外部参数（如镜像标签、环境变量）已经变化，回滚后的状态可能与预期不符。
- kubectl rollout undo： 仅回滚 Deployment 的 Pod 模板，不涉及 ConfigMap、Service 等关联资源，容易导致部分回滚。
GitOps 的回滚机制天然解决了这些问题：
- 原子性回滚： 执行 git revert <commit-hash> 后，Git 仓库回到历史状态，Operator 自动将整个集群状态回退到该 commit 对应的所有资源配置。
- 可审计性： 每次回滚都对应一条 Git 提交记录，包含回滚原因、操作人、时间戳。
- 一致性保障： 回滚后的状态与历史 commit 完全一致，不存在配置漂移。
课程预告： 本章后续将深入 GitOps 回滚的三种实战模式——全量回滚、渐进式回滚与金丝雀回滚，并配合 Argo CD 与 Flux 的完整配置示例。