1. 课程导论与背景：什么是策略即代码（Policy as Code），为什么在GitOps中需要策略引擎，Kyverno的定位与优势
1.1 从传统策略管理到策略即代码（Policy as Code）
在云原生与Kubernetes生态中，策略管理正经历一场根本性的范式转移。传统策略通常以文档、人工审批或硬编码逻辑的形式存在，缺乏可审计性、可重复性和自动化能力。策略即代码（Policy as Code, PaC） 将策略声明为机器可读、版本可控、可自动执行的代码工件，使其融入软件交付生命周期。
策略即代码的核心特征包括：
- 声明式：策略以声明式语言（如YAML、Rego、CEL）定义，而非过程式脚本。
- 版本化：策略存储在Git仓库中，与应用程序代码一同接受版本控制。
- 自动化执行：策略在CI/CD流水线或集群准入控制阶段自动评估，无需人工介入。
- 可审计：策略变更历史、评估结果、违规记录均可追溯。
- 可测试：策略可以像代码一样编写单元测试和集成测试。
关键洞察：策略即代码将安全、合规与治理左移到开发早期，从“事后检查”转变为“事前预防”，是平台工程与DevSecOps的核心实践之一。
1.2 为什么在GitOps中需要策略引擎
GitOps以Git仓库作为单一事实来源，通过自动化同步机制将声明式配置推送到目标环境。然而，GitOps的自动化特性也带来了新的治理挑战：
| 挑战维度 | 具体问题 | 传统方案局限 |
|---|---|---|
| 配置漂移 | 开发人员可能提交不符合安全基线或资源限制的YAML | 人工Code Review效率低、易遗漏 |
| 合规要求 | 需要确保所有Namespace、Pod、Service满足PCI-DSS、SOC2等标准 | 手动巡检无法持续，且难以规模化 |
| 多集群一致性 | 不同集群（开发/预发/生产）需要统一策略基线 | 脚本分散、版本混乱、缺乏统一视图 |
| 变更风险 | 自动同步可能将不合规配置直接推送到生产集群 | 缺乏准入控制，风险暴露窗口大 |
| 审计与追溯 | 需要证明每个资源变更都经过了策略校验 | 日志分散、难以关联Git提交与策略评估结果 |
在GitOps架构中引入策略引擎，可以在Git提交阶段（Pre-commit / CI）和集群准入阶段（Admission Controller）设置两道防线，确保只有符合策略的配置才能进入集群。策略引擎与GitOps的协同关系如下图所示：
最佳实践：在GitOps流水线中，建议将策略检查分为两层——CI层执行快速、轻量的策略校验（如命名规范、标签要求），准入层执行更严格的安全与合规策略（如禁止特权容器、限制资源配额）。两层互补，既保证开发效率，又守住安全底线。
1.3 Kyverno的定位与优势
Kyverno是专为Kubernetes设计的策略引擎，由Nirmata开源，目前是CNCF（云原生计算基金会）的孵化项目。与通用策略引擎（如OPA/Gatekeeper）不同，Kyverno采用Kubernetes原生的设计哲学，使用标准的Kubernetes资源（CRD）来定义策略，无需学习新的策略语言（如Rego）。
Kyverno在GitOps架构中的核心定位如下：
- 策略即Kubernetes资源：策略本身以YAML格式定义，可直接存储在Git仓库中，与应用程序配置一同进行版本控制。
- 无额外语言负担：策略编写者只需掌握Kubernetes YAML语法，无需学习Rego、OPA等外部语言，降低团队学习成本。
- 原生准入控制：作为Kubernetes Admission Webhook运行，在资源创建、更新时自动拦截并评估策略。
- 支持多种策略类型：包括验证（Validate）、变更（Mutate）、生成（Generate）和图像验证（Image Verify）。
- GitOps友好：策略变更通过Git提交触发，与Argo CD、Flux等GitOps工具无缝集成。
下表对比了Kyverno与其他主流策略引擎在GitOps场景下的关键差异：
| 特性维度 | Kyverno | OPA / Gatekeeper | jsPolicy |
|---|---|---|---|
| 策略语言 | Kubernetes YAML（无额外语言） | Rego（需学习新语言） | JavaScript / TypeScript |
| 策略存储 | CRD资源，原生Git友好 | ConstraintTemplate + Constraint | CRD资源 |
| 变更策略 | 原生支持（Mutate） | 需额外配置 | 原生支持 |
| 生成策略 | 原生支持（Generate） | 不支持 | 不支持 |
| 图像验证 | 原生支持（Image Verify） | 需结合外部工具 | 不支持 |
| GitOps集成复杂度 | 低（策略即YAML，直接同步） | 中（需管理Template与Constraint两层） | 中 |
| 社区生态 | CNCF孵化项目，策略库丰富 | CNCF毕业项目，生态成熟 | 较小众 |
Kyverno的策略定义示例（验证Pod必须包含特定标签）：
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-pod-labels
spec:
validationFailureAction: Enforce
rules:
- name: check-required-labels
match:
any:
- resources:
kinds:
- Pod
validate:
message: "Pod必须包含 'app.kubernetes.io/name' 标签"
pattern:
metadata:
labels:
app.kubernetes.io/name: "?*"
注意：虽然Kyverno的策略定义简单直观，但在大规模集群或复杂策略场景下，仍需注意策略的匹配范围（match/exclude）和性能影响。建议在GitOps流水线中先通过CI阶段进行策略预检，减少准入阶段的拒绝次数。
1.4 Kyverno在GitOps中的核心优势总结
综合以上分析，Kyverno在GitOps架构中具备以下不可替代的优势：
- 策略与配置同源：策略作为Kubernetes YAML存储在Git仓库中，与应用程序配置共享同一套版本控制、Code Review和CI/CD流程。
- 降低认知负荷：团队无需学习额外的策略语言，Kubernetes开发者可以快速上手编写和审查策略。
- 全生命周期覆盖：从CI预检到集群准入，从资源验证到自动变更，Kyverno提供端到端的策略执行能力。
- GitOps Operator原生集成：Argo CD和Flux等工具可以直接同步Kyverno策略资源，无需额外适配。
- 策略即文档：YAML格式的策略本身具有自描述性，配合Kyverno的测试框架（Kyverno CLI），可以生成可执行的策略文档。