2. GitOps 基础：核心原则、工作流与常用工具
GitOps 是将 DevOps 最佳实践与基础设施即代码（IaC）相结合的一种运营模型，其核心思想是将 Git 仓库作为整个系统的单一事实来源（Single Source of Truth）。在《Kyverno 策略驱动 GitOps 调度优化实践》课程中，理解 GitOps 的基石是后续利用 Kyverno 策略进行调度干预的前提。
2.1 GitOps 核心原则
GitOps 建立在三大支柱之上：声明式、版本控制和自动化。这三者共同确保了系统的可审计性、可复现性和自愈能力。
| 原则 | 核心描述 | 在 Kubernetes 中的体现 |
|---|---|---|
| 声明式 | 系统状态由用户期望的配置（Desired State）定义，而非操作步骤。 | YAML 清单（Deployment、Service、Namespace）描述集群的最终状态。 |
| 版本控制 | 所有声明式配置都存储在 Git 仓库中，每次变更都产生可追溯的提交记录。 | 通过 Git 提交历史回滚或审计任何资源变更。 |
| 自动化 | 集群持续与 Git 仓库中的期望状态进行比对，自动纠正漂移。 | Operator 或控制器自动应用变更，无需手动 kubectl apply。 |
kubectl edit 手动修改了资源，GitOps 工具会自动将其还原为 Git 仓库中的版本，这就是“自愈”能力。
2.2 GitOps 工作流：Push vs Pull
GitOps 的自动化实现主要分为两种架构模式：Push 模式和Pull 模式。在云原生生态中，Pull 模式已成为主流。
2.2.1 Push 模式
在 Push 模式中，CI/CD 管道（如 Jenkins、GitHub Actions）拥有对集群的访问权限。当代码合并到主分支后，管道直接执行 kubectl apply 或 helm upgrade 将配置推送到集群。
- 优点： 实现简单，与现有 CI 工具集成度高。
- 缺点： 需要将集群凭证暴露给 CI 系统，安全风险较高；集群状态与 Git 仓库的绑定较弱。
2.2.2 Pull 模式
在 Pull 模式中，集群内部运行一个 Operator（如 Argo CD、Flux），该 Operator 主动监听 Git 仓库的变化，并将期望状态拉取到集群中。CI 管道仅负责将代码构建为镜像并更新 Git 仓库中的清单。
- 优点： 安全性高（集群无需对外暴露 API）、状态强一致、天然支持多集群管理。
- 缺点： 需要额外部署 Operator，架构相对复杂。
2.3 常用 GitOps 工具：Argo CD 与 Flux
目前社区最流行的两款 GitOps 工具是 Argo CD 和 Flux。它们都采用 Pull 模式，但在设计哲学和功能侧重点上有所不同。
2.3.1 Argo CD
Argo CD 是 CNCF 毕业项目，以其强大的 Web UI 和 Application 抽象著称。它允许用户通过 Application CRD 定义应用来源与目标集群。
- 核心特性： 可视化 Dashboard、SSO 集成、多集群管理、Sync 策略（手动/自动）、Prune 资源。
- 适用场景： 需要频繁进行人工审核和手动同步的团队，或需要直观查看应用状态的环境。
2.3.2 Flux
Flux 是 CNCF 孵化项目，强调“Kubernetes 原生”和“无需外部数据库”。它基于 source.toolkit.fluxcd.io 和 kustomize.toolkit.fluxcd.io 等 API 构建。
- 核心特性： 完全基于 CRD 驱动、支持多租户（Tenancy）、依赖管理（DependsOn）、Webhook 接收器（Notification Controller）。
- 适用场景： 追求极简架构、希望完全通过 Git 和 CRD 管理一切、对多租户隔离有严格要求的平台团队。
2.3.3 工具对比一览
| 维度 | Argo CD | Flux |
|---|---|---|
| 架构 | Application CRD + API Server + Repo Server | Source Controller + Kustomize Controller + Helm Controller |
| UI 界面 | 功能丰富，支持拓扑图 | 无内置 UI，依赖 CLI 或第三方 |
| 多租户 | 通过 Project 实现 | 原生支持，基于 Kustomize 和 RBAC |
| 同步策略 | 支持自动同步、手动同步、Prune | 自动同步为主，支持手动干预 |
| Helm 支持 | 支持 Helm Chart 和 OCI 仓库 | 支持 HelmRelease CRD，功能更深入 |
2.4 GitOps 工作流全景图
下图展示了一个基于 Pull 模式的完整 GitOps 工作流，涵盖了从代码提交到集群状态调和的完整链路。这也是本课程后续章节中 Kyverno 策略介入的上下文环境。
- 开发者将代码和 Kubernetes 清单推送到 Git 仓库。
- CI 管道构建镜像并推送到镜像仓库，同时更新 Git 仓库中的清单（如 Deployment 的镜像 Tag）。
- GitOps Operator 检测到 Git 仓库变更，拉取最新清单。
- Operator 将清单与集群当前状态进行比对，并执行调和操作（创建/更新/删除资源）。
- 在资源应用到集群前，Kyverno 策略引擎作为准入控制器进行校验和变异，确保资源符合调度策略。