1. GitOps 基础概念
GitOps 是一种以 Git 仓库作为单一事实来源（Single Source of Truth）的云原生运维模式。它将声明式基础设施与版本控制、自动化交付流水线深度结合，使整个应用交付与基础设施变更可审计、可回滚、可协作。理解 GitOps 的核心原则，是后续在 Kubernetes 集群中落地 Kyverno 策略引擎的前提。
1.1 GitOps 定义
GitOps 由 Weaveworks 在 2017 年正式提出，其核心思想是：用 Git 仓库描述整个系统的期望状态，并通过自动化 Operator 持续将实际集群状态向 Git 中声明的状态收敛。在 GitOps 模型中，所有基础设施定义、应用配置、策略规则都以代码形式存储在 Git 仓库中，任何对集群的变更都必须通过 Pull Request 发起，经审核后合并到主分支，再由 GitOps Operator 自动同步到目标环境。
关键定义： GitOps = 声明式基础设施 + 版本控制 + 自动化同步 + 可观测性。
1.2 核心原则
GitOps 建立在以下三大核心原则之上，这些原则直接决定了 Kyverno 策略在 GitOps 架构中的设计方式：
| 原则 | 说明 | 对 Kyverno 策略的影响 |
|---|---|---|
| 声明式（Declarative） | 系统期望状态以声明式 YAML/JSON 描述，而非命令式脚本。Operator 负责调和实际状态与期望状态。 | Kyverno 策略本身也是声明式资源（ClusterPolicy/Policy），可纳入 Git 管理。 |
| 版本控制（Version Control） | 所有变更通过 Git 提交记录，支持分支策略、Code Review、标签与回滚。 | 策略变更必须走 PR 流程，确保合规审计与变更追溯。 |
| 自动化（Automation） | GitOps Operator（如 Argo CD、Flux）自动检测 Git 仓库变更并同步到集群，无需手动 kubectl apply。 | 策略的部署、更新、回滚由 Operator 自动执行，减少人工误操作。 |
实践提示： 在 GitOps 架构中，Kyverno 策略应作为“策略即代码”的一部分，与业务应用配置存放在同一 Git 仓库的不同目录下，或独立存放在策略仓库中，通过 ApplicationSet / Kustomize 进行环境差异化管理。
1.3 与传统 CI/CD 的区别
传统 CI/CD 管道通常以“构建-测试-部署”的流水线方式运行，部署阶段依赖人工或脚本执行 kubectl / helm upgrade。GitOps 则从根本上改变了交付模型。以下对比表清晰展示了两者的差异：
| 维度 | 传统 CI/CD | GitOps |
|---|---|---|
| 部署触发方式 | CI 管道完成后，通过脚本或手动触发部署 | Git 仓库主分支变更后，Operator 自动同步 |
| 状态管理 | 部署结果依赖管道日志，集群状态可能漂移 | Git 仓库始终是期望状态，Operator 持续调和 |
| 回滚方式 | 重新运行旧版本管道或手动恢复 | git revert 或切换分支，Operator 自动回滚 |
| 权限模型 | CI 系统通常持有集群凭据，存在安全风险 | Operator 持有凭据，开发者仅需 Git 权限 |
| 审计与合规 | 依赖管道日志，变更记录分散 | 所有变更通过 Git commit 记录，天然可审计 |
| 策略执行时机 | 通常在 CI 阶段做静态检查，运行时缺乏管控 | 可在同步前（Pre-sync Hook）和运行时（Admission Controller）双重执行 |
常见误区： GitOps 并不是要完全取代 CI 管道。CI 阶段仍然负责代码编译、单元测试、镜像构建与扫描；GitOps 接管的是“部署与持续调和”阶段。Kyverno 策略可以在 CI 阶段（通过 kyverno-cli 预检）和 GitOps 同步阶段（通过 Admission Webhook）同时生效，形成双重防护。
1.4 GitOps 工作流全景
下图展示了 GitOps 架构中从代码提交到集群同步的完整工作流，以及 Kyverno 策略在其中的介入点：
1.5 GitOps 中的策略管理模型
在 GitOps 架构中，策略管理遵循与应用程序相同的 Git 工作流。下图展示了策略从定义到生效的完整生命周期：
1.6 为什么 GitOps 需要策略引擎
在 GitOps 架构中，虽然 Git 仓库作为单一事实来源，但仅靠 Git 无法保证以下安全与合规需求：
- 配置漂移检测： 即使 Operator 持续调和，仍可能存在临时 kubectl 修改或恶意注入，需要策略引擎持续审计。
- 安全基线强制： 确保所有部署的容器满足 Pod Security Standards、禁止特权容器、强制只读根文件系统等。
- 多租户隔离： 在共享集群中，不同团队的应用必须遵守资源配额、网络策略、命名空间隔离规则。
- 合规审计： 金融、医疗等行业要求所有配置变更可追溯，策略执行结果需记录为审计日志。
- 预检与准入双重控制： CI 阶段通过 kyverno-cli 做静态预检，集群侧通过 Admission Webhook 做运行时准入，形成完整防护链。
核心结论： GitOps 提供了“声明式 + 版本控制 + 自动化”的基础设施交付框架，而 Kyverno 策略引擎则为这个框架注入了“安全 + 合规 + 治理”的能力。两者结合，才能构建生产级、可审计、自愈的云原生平台。