1. GitOps 概述：定义、核心原则与传统 CI/CD 的区别
GitOps 是一种以 Git 仓库作为单一事实来源（Single Source of Truth）的云原生运维模式。它将声明式配置与版本控制相结合，通过自动化机制确保集群的实际状态始终与 Git 中定义的期望状态保持一致。本节将系统阐述 GitOps 的定义、三大核心原则，并通过对比表格清晰展示其与传统 CI/CD 的根本差异。
1.1 GitOps 的定义
GitOps 由 Weaveworks 在 2017 年首次提出，其核心思想是：将整个系统的声明式描述存储在 Git 仓库中，并通过自动化工具（如 Argo CD、Flux）持续将集群状态同步至该描述。在 GitOps 模型中，Git 仓库不仅是代码的存储地，更是基础设施和应用程序配置的权威来源。任何对系统的变更，都必须通过 Pull Request（PR）提交至 Git，经审核合并后，由 Operator 自动应用到目标环境。
关键定义： GitOps = 声明式配置 + 版本控制（Git）+ 自动化同步（Operator）。
1.2 三大核心原则
GitOps 的实践建立在以下三个不可分割的核心原则之上，它们共同构成了 GitOps 的信任基础与自动化闭环。
| 原则 | 描述 | 关键实践 |
|---|---|---|
| 声明式（Declarative） | 系统的期望状态（如 Kubernetes YAML 清单）被完整、明确地描述，而非通过一系列命令逐步执行。 | 所有资源定义（Deployment、Service、ConfigMap）均以声明式文件形式存在。 |
| 版本控制（Version Control） | Git 仓库作为单一事实来源，记录每一次变更的历史、作者和原因，支持回滚与审计。 | 所有配置变更必须通过 PR 提交，禁止直接修改集群状态。 |
| 自动化（Automation） | 由 GitOps Operator 自动检测 Git 仓库与集群之间的差异，并执行同步操作，无需人工介入。 | Operator 持续运行 Reconciliation Loop（调谐循环），确保集群状态收敛于 Git 状态。 |
实践提示： 声明式是 GitOps 的基石。如果系统状态是通过脚本或命令式操作维护的，则无法实现真正的 GitOps 自动化与可审计性。
1.3 GitOps 与传统 CI/CD 的区别
传统 CI/CD 管道（如 Jenkins、GitLab CI）侧重于“构建-测试-部署”的流水线自动化，而 GitOps 则从根本上改变了部署模型：从“推送”变为“拉取”。以下表格从多个维度对比两者的核心差异。
| 对比维度 | 传统 CI/CD | GitOps |
|---|---|---|
| 部署模型 | 推送模型（Push）：CI 管道将构建产物或配置推送到目标环境。 | 拉取模型（Pull）：Operator 从 Git 仓库拉取期望状态并同步至集群。 |
| 配置来源 | 分散在 CI 脚本、配置文件、环境变量中，缺乏统一管理。 | 单一事实来源：所有配置集中存储在 Git 仓库中。 |
| 变更方式 | 通过 CI 管道触发部署，变更可能绕过审核直接执行。 | 所有变更必须通过 PR 提交，经 Code Review 后合并，Operator 自动同步。 |
| 状态收敛 | 管道执行完成后即结束，不持续监控集群状态是否偏离。 | Operator 持续运行调谐循环，自动修复漂移（Drift），确保状态收敛。 |
| 回滚机制 | 依赖管道重新执行或手动恢复，回滚过程可能复杂且易出错。 | 通过 Git revert 或 checkout 到历史 commit，Operator 自动将集群回滚至旧状态。 |
| 安全模型 | CI 系统通常需要持有集群的凭据（如 kubeconfig），存在安全风险。 | Operator 在集群内部运行，无需对外暴露集群凭据，安全性更高。 |
1.4 GitOps 工作流架构图
下图展示了 GitOps 的核心工作流：开发人员通过 PR 将声明式配置提交至 Git 仓库，GitOps Operator 持续监控仓库变化，并将期望状态同步至 Kubernetes 集群。
1.5 传统 CI/CD 与 GitOps 流程对比图
为了更直观地理解两种模型的差异，下图分别展示了传统 CI/CD 的“推送”模型与 GitOps 的“拉取”模型。
常见误区： GitOps 并非要完全取代 CI 管道。CI 仍然负责代码的构建、单元测试和镜像打包，而 GitOps 接管的是“部署”与“运维”阶段。两者是互补关系，而非替代关系。
1.6 为什么选择 GitOps？
GitOps 为云原生环境带来了以下关键收益，使其成为现代 Kubernetes 运维的首选模式：
- 可审计性： 每一次变更都有完整的 Git 历史记录，包括谁、何时、为什么修改，满足合规要求。
- 快速回滚： 只需执行
git revert或切换到旧 commit，Operator 自动将集群恢复至历史状态。 - 减少配置漂移： Operator 持续检测并修复集群状态与 Git 状态之间的差异，确保环境一致性。
- 提升安全性： 集群凭据无需暴露给 CI 系统或开发人员，Operator 在集群内部安全运行。
- 团队协作： 所有变更通过 PR 流程进行 Code Review，降低人为失误风险。
适用场景： GitOps 特别适合多集群管理、边缘部署、需要严格合规审计的生产环境，以及追求“基础设施即代码”最佳实践的团队。