1. GitOps 基础概念
1.1 GitOps 定义
GitOps 是一种以 Git 仓库作为单一事实来源（Single Source of Truth）的云原生运维模式。它将整个交付系统的期望状态声明式地存储在 Git 中，并通过自动化机制持续确保运行环境与 Git 中的声明状态保持一致。GitOps 的核心思想是：一切变更从 Git 发起，一切状态以 Git 为准。
核心公式： GitOps = 声明式基础设施 + 版本控制 + 自动化同步
1.2 核心原则
GitOps 建立在三大核心原则之上，这些原则共同构成了其与传统 CI/CD 的本质区别：
| 原则 | 说明 | 关键要求 |
|---|---|---|
| 声明式（Declarative） | 描述系统“应该是什么状态”，而非“如何达到该状态” | 所有资源（Deployment、Service、ConfigMap 等）以 YAML/JSON 定义 |
| 版本控制（Version Controlled） | Git 仓库存储完整的期望状态历史，支持回滚、审计、协作 | 每次变更产生 commit，可追溯、可复现、可审查 |
| 自动化同步（Automated Sync） | Operator/Agent 持续对比 Git 状态与集群实际状态，自动调和差异 | 无需手动 kubectl apply，由工具（Argo CD / Flux）自动执行 |
实践要点： 声明式是 GitOps 的基石。如果资源定义中包含脚本式逻辑（如 shell 脚本、动态参数注入），则破坏了声明式原则，应将其重构为纯声明式配置。
1.3 GitOps 与传统 CI/CD 的区别
传统 CI/CD 以“流水线”为中心，强调构建、测试、部署的流程编排；GitOps 以“Git 仓库”为中心，强调状态声明与自动调和。以下从多个维度进行对比：
| 对比维度 | 传统 CI/CD | GitOps |
|---|---|---|
| 状态管理 | 流水线执行后，集群状态与流水线日志绑定，无统一状态视图 | Git 仓库始终持有期望状态，集群实际状态可随时与 Git 对比 |
| 部署触发 | 通常由 CI 构建完成触发 CD 流水线 | Git 仓库变更（push / PR merge）触发自动同步 |
| 回滚方式 | 重新执行上一版本的流水线，或手动执行回滚脚本 | git revert 到上一 commit，Operator 自动将集群回滚到该状态 |
| 权限模型 | CI/CD 系统拥有集群凭据，开发者间接操作集群 | 仅 GitOps Operator 持有集群凭据，开发者只操作 Git |
| 审计能力 | 依赖 CI/CD 平台日志，审计链路不完整 | Git commit 历史 = 完整审计日志，含变更人、时间、内容 |
| 环境一致性 | 不同环境（dev/staging/prod）的配置可能分散在多个分支或仓库 | 所有环境配置统一管理，通过目录结构或分支策略隔离 |
1.4 GitOps 工作流程示意图
下图展示了 GitOps 的核心工作流：开发者提交变更到 Git 仓库，GitOps Operator 检测到差异后自动将期望状态同步到目标集群。
1.5 GitOps 与传统 CI/CD 架构对比
为了更直观地理解两者的架构差异，下图展示了传统 CI/CD 与 GitOps 在部署流程上的根本区别：
1.6 为什么 GitOps 适合资源配额校准场景
在 Kubernetes 集群中，资源配额（ResourceQuota、LimitRange）的管理面临以下挑战：
- 多环境配置漂移： dev/staging/prod 的配额参数容易不一致
- 变更不可追溯： 谁在什么时候修改了哪个 Namespace 的配额，缺乏审计
- 回滚困难： 错误的配额调整可能导致 Pod 调度失败，手动恢复效率低
GitOps 通过以下能力解决上述问题：
- 单一事实来源： 所有配额配置统一存储在 Git 仓库中，环境间通过目录或分支隔离
- 自动调和： Operator 持续确保集群配额与 Git 一致，避免配置漂移
- 快速回滚： 配额调整失误时，执行
git revert即可自动恢复 - 审计合规： 每次配额变更都有完整的 commit 记录，满足合规要求
常见误区： 不要将 GitOps 等同于“用 Git 存储 YAML 文件”。真正的 GitOps 必须包含自动同步机制（Operator），否则只是“Git 存储 + 手动部署”，无法享受自动调和带来的故障自愈能力。