1. GitOps 基础概念
GitOps 是一种以 Git 仓库作为单一事实来源（Single Source of Truth）的云原生运维模式。它将声明式基础设施与版本控制系统相结合，通过自动化机制确保集群的实际状态始终与 Git 仓库中定义的期望状态保持一致。本节将系统阐述 GitOps 的定义、核心原则及其与传统 CI/CD 的根本差异。
1.1 GitOps 定义
GitOps 由 Weaveworks 在 2017 年正式提出，其核心思想是：将整个系统的期望状态（包括应用代码、基础设施配置、策略规则）全部声明式地存储在 Git 仓库中，并通过自动化 Operator 持续将集群实际状态向 Git 中的期望状态收敛。任何对系统的变更都必须通过 Git 提交（Pull Request / Merge Request）来发起，变更的审批、回滚、审计也全部基于 Git 的历史记录。
关键定义： GitOps = 声明式基础设施 + 版本控制 + 自动化同步 + 可审计性。
1.2 核心原则
GitOps 建立在以下四项核心原则之上，这些原则共同构成了其与传统运维模式的分水岭：
| 原则 | 说明 | 实践体现 |
|---|---|---|
| 声明式（Declarative） | 系统期望状态以声明式配置描述，而非命令式脚本 | Kubernetes YAML、Terraform HCL、Crossplane Composition |
| 版本控制（Version Controlled） | 所有配置变更通过 Git 提交记录，提供完整审计轨迹 | Git 历史、标签、分支策略、PR 审批流程 |
| 自动化（Automated） | Operator 自动检测 Git 变更并同步到目标环境 | Argo CD、Flux CD、Jenkins X |
| 可审计（Auditable） | 每次变更都有明确的作者、时间、原因和影响范围 | Git 日志、签名提交、合规报告 |
实践提示： 在资源配额校准与权限审计场景中，声明式原则意味着所有 Namespace 的 ResourceQuota、LimitRange、RBAC 绑定都必须以 YAML 形式存在于 Git 仓库中，任何手动
kubectl edit 或 kubectl create 操作都视为违反 GitOps 规范。
1.3 GitOps 与传统 CI/CD 的区别
传统 CI/CD 管道（如 Jenkins、GitLab CI）侧重于“构建-测试-部署”的自动化流水线，而 GitOps 将 Git 仓库提升为整个交付流程的“控制平面”。两者在架构、变更驱动方式和回滚机制上存在本质差异：
| 维度 | 传统 CI/CD | GitOps |
|---|---|---|
| 配置存储 | 分散在 CI 脚本、配置文件、数据库、环境变量中 | 全部集中在 Git 仓库，单一事实来源 |
| 变更驱动 | CI 触发（代码提交、定时、手动） | Git 仓库状态变更（PR 合并、标签推送） |
| 部署方式 | Push 模式：CI 服务器主动推送至目标环境 | Pull 模式：集群内 Operator 主动拉取 Git 状态 |
| 状态收敛 | 部署后不持续监控，漂移需人工介入 | Operator 持续对比并自动修复漂移 |
| 回滚操作 | 回滚需重新触发 CI 管道或执行脚本 | 回滚即 git revert，Operator 自动同步 |
| 审计能力 | 依赖 CI 日志和外部审计系统 | Git 历史天然提供完整审计轨迹 |
| 典型工具 | Jenkins、GitLab CI、CircleCI | Argo CD、Flux CD、Rancher Fleet |
常见误区： GitOps 并非要完全取代 CI/CD。CI 阶段（代码编译、单元测试、镜像构建）仍然保留在传统 CI 管道中；GitOps 接管的是 CD 阶段（部署、同步、漂移修复）。正确的分工是：CI 产出制品（如容器镜像），GitOps 负责将制品声明式地交付到目标环境。
1.4 GitOps 工作流架构
下图展示了 GitOps 的核心工作流：开发人员通过 Git 提交变更，CI 管道构建镜像并更新配置仓库，GitOps Operator 从配置仓库拉取期望状态并与集群实际状态进行差异对比，最终自动执行同步操作。
1.5 GitOps 在资源配额校准中的价值
在《Kustomize GitOps 交付资源配额校准权限审计》课程中，GitOps 为资源配额管理带来了以下关键能力：
- 配额声明化： 所有 Namespace 的
ResourceQuota和LimitRange以 Kustomize overlay 形式存储在 Git 仓库中，环境差异通过 Patch 机制管理。 - 变更可追溯： 每次配额调整都对应一个 Git 提交，包含调整原因、审批人和影响范围，满足合规审计要求。
- 自动校准： GitOps Operator 持续监控集群配额实际值，当发现与 Git 定义不一致时自动校准，防止手动误操作导致的配额超限或资源浪费。
- 权限绑定： RBAC 配置与配额配置同仓管理，确保“谁可以调整配额”与“配额值是多少”的变更权限统一受 Git 控制。