1. GitOps 基础概念
1.1 GitOps 定义
GitOps 是一种以 Git 仓库作为单一事实来源（Single Source of Truth）的云原生运维模式。它将声明式基础设施与版本控制系统相结合，通过自动化流程确保集群的实际状态与 Git 仓库中定义的期望状态始终保持一致。在 GitOps 模型中，所有对环境的变更都必须通过 Git 提交（Commit）和合并请求（Merge Request）来驱动，任何手动操作都被视为偏离规范。
核心思想：“Git 仓库是系统的唯一真相源，一切变更皆可追溯、可审计、可回滚。”
1.2 核心原则
GitOps 建立在三大支柱之上，三者缺一不可：
| 原则 | 说明 | 关键要求 |
|---|---|---|
| 声明式（Declarative） | 所有基础设施和应用配置都以声明式清单（YAML/JSON）描述，而非命令式脚本。 | Kubernetes 原生资源、Helm Chart、Kustomize 覆盖层 |
| 版本控制（Version Controlled） | 所有声明式清单存储在 Git 仓库中，每次变更都产生可追溯的提交记录。 | 分支策略、标签、签名提交、访问控制 |
| 自动化（Automated） | 由 GitOps Operator（如 Argo CD、Flux）自动将 Git 中的期望状态同步到目标集群。 | 轮询或 Webhook 触发、自动同步、漂移检测 |
实践要点：声明式是基础，版本控制是保障，自动化是执行引擎。缺少任何一环都会退化为“伪 GitOps”。
1.3 GitOps 与传统 CI/CD 的区别
传统 CI/CD 以“构建-测试-部署”管道为中心，而 GitOps 将部署阶段彻底重构为“状态同步”模型。以下从多个维度进行对比：
| 维度 | 传统 CI/CD | GitOps |
|---|---|---|
| 真相源 | CI 脚本 + 手动配置 + 运行时状态 | Git 仓库（单一真相源） |
| 部署方式 | 管道推送（Push）：CI 服务器将制品推送到目标环境 | Operator 拉取（Pull）：集群内的 Agent 从 Git 拉取期望状态 |
| 变更驱动 | 手动触发或 CI 事件触发 | Git 提交 / 合并请求 |
| 回滚策略 | 重新运行旧管道或手动恢复 | git revert 或切换分支，Operator 自动同步 |
| 漂移检测 | 无原生机制，依赖监控告警 | 内置持续调和（Reconciliation），自动检测并告警/修复 |
| 安全模型 | CI 系统需要集群凭证，攻击面大 | Operator 仅需只读权限，凭证不离开集群 |
常见误区：GitOps 不是要取代 CI，而是将 CI 与 CD 解耦。CI 仍然负责构建和测试制品（如容器镜像），CD 部分则完全由 GitOps 接管。镜像版本的变化通过更新 Git 仓库中的清单来触发部署。
1.4 GitOps 工作流全景
下图展示了 GitOps 从代码提交到集群同步的完整闭环流程：
1.5 GitOps 与传统 CI/CD 架构对比
下图从架构层面直观展示 Push 模型（传统）与 Pull 模型（GitOps）的本质差异：
1.6 为什么在资源配额校准与 Envoy 网关场景中需要 GitOps
在云原生环境中，资源配额（Resource Quota）和 Envoy 网关配置的频繁变更是导致故障的两大常见原因。GitOps 为这两个场景提供了结构化的治理手段：
- 资源配额校准：通过 Git 仓库管理 Namespace 级别的
ResourceQuota和LimitRange，每次调整都经过代码审查（Code Review），避免“拍脑袋”式修改导致集群过载或资源浪费。 - Envoy 网关配置：Envoy 的 Listener、Cluster、Route 等配置以声明式清单（如 EnvoyFilter、Gateway API 资源）存储在 Git 中，Operator 自动同步到网格或网关实例，配置回滚只需
git revert。 - 故障排查：Git 提交历史提供了完整的变更时间线，结合 Operator 的同步日志，可以快速定位“谁在什么时间改了哪个配置”以及“同步是否成功”。