3、Kyverno简介：Kyverno项目背景、核心能力（策略即代码），与OPA/Gatekeeper的对比
3.1 项目背景与定位
Kyverno 是一个由 Nirmata 公司发起、后捐赠给 CNCF 的 Kubernetes 原生策略引擎，于 2021 年进入 CNCF Incubating 阶段。其设计哲学是“策略即代码”（Policy as Code），但与其他方案最大的区别在于：Kyverno 使用 Kubernetes 资源（CRD）来定义策略，而非通用编程语言或 DSL。
这意味着任何熟悉 Kubernetes 资源清单的工程师，都可以用 YAML 直接编写策略，无需学习 Rego、Lua 或 JavaScript 等额外语言。Kyverno 以 Admission Webhook 的形式运行在集群内，拦截资源创建/更新请求，并根据策略规则进行验证、变更或生成资源。
核心定位： Kyverno 不是通用策略引擎，而是专为 Kubernetes 设计的策略引擎。它深度集成 Kubernetes 原生对象模型，天然支持 Namespace、Label、Annotation、ServiceAccount 等 Kubernetes 概念。
3.2 核心能力：策略即代码
Kyverno 的策略模型围绕三个核心动作构建，覆盖了准入控制的完整生命周期：
| 动作类型 | 策略关键字 | 功能描述 | 典型场景 |
|---|---|---|---|
| 验证（Validate） | validate |
检查资源是否符合规则，不符合则拒绝创建/更新 | 强制 Pod 必须设置资源限制、禁止使用 latest 镜像标签 |
| 变更（Mutate） | mutate |
在资源持久化前自动修改其字段 | 自动注入 Sidecar、添加默认 Label、设置 Pod 安全上下文 |
| 生成（Generate） | generate |
根据源资源自动创建关联资源 | 为每个 Namespace 自动创建 NetworkPolicy、ResourceQuota |
以下是一个典型的验证策略示例，禁止 Pod 使用 latest 镜像标签：
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: disallow-latest-tag
spec:
validationFailureAction: Enforce
rules:
- name: require-image-tag
match:
any:
- resources:
kinds:
- Pod
validate:
message: "使用 'latest' 标签的镜像是不允许的。"
pattern:
spec:
containers:
- image: "!*:latest"
策略即代码的关键特征：
- 声明式： 策略以 YAML 资源清单形式存在，可纳入 GitOps 流程。
- 可测试： 支持
kyverno test命令对策略进行单元测试。 - 可观测： 提供策略执行报告（PolicyReport）和集群策略报告（ClusterPolicyReport）。
- 可组合： 支持策略集（PolicySet）和策略异常（PolicyException）。
3.3 与 OPA/Gatekeeper 的对比
OPA（Open Policy Agent）结合 Gatekeeper 是目前 Kubernetes 生态中最广泛使用的策略引擎方案。两者在架构、策略语言、运维复杂度上存在显著差异。以下从多个维度进行对比：
| 对比维度 | Kyverno | OPA + Gatekeeper |
|---|---|---|
| 策略语言 | YAML（Kubernetes 原生资源） | Rego（声明式查询语言） |
| 学习曲线 | 低：熟悉 K8s YAML 即可上手 | 高：需学习 Rego 语法和逻辑 |
| 架构模式 | 单一 Webhook + CRD 控制器 | OPA 作为独立服务 + Gatekeeper 作为 Webhook 适配器 |
| 变更能力 | 原生支持 mutate 动作 | 需额外编写 Rego 规则实现，复杂度高 |
| 生成能力 | 原生支持 generate 动作 | 不支持，需外部控制器配合 |
| 策略分发 | 通过 ClusterPolicy/Policy CRD 分发 | 通过 ConstraintTemplate + Constraint CRD 分发 |
| 性能开销 | 低：策略编译为 JSON 规则直接匹配 | 中：Rego 查询需 OPA 引擎评估 |
| 社区生态 | CNCF Incubating，策略库 300+ | CNCF Graduated，策略库 1000+ |
| 灾备场景适配 | 强：原生支持 mutate/generate，适合自动化注入 | 中：需额外开发 Rego 规则实现类似功能 |
选型建议： 如果团队以 Kubernetes 工程师为主，追求低学习成本和快速落地，Kyverno 是更优选择；如果团队已有 Rego 经验或需要跨 Kubernetes 的通用策略能力（如 Terraform、Docker、HTTP API），OPA/Gatekeeper 更合适。在灾备场景中，Kyverno 的 mutate 和 generate 能力可以显著降低自动化注入 Sidecar、配置网络策略的复杂度。
3.4 Kyverno 架构概览
下图展示了 Kyverno 的核心组件及其在 Kubernetes 集群中的部署架构：
3.5 策略执行流程
当用户通过 kubectl apply 提交资源时，Kyverno 的准入控制流程如下：
- 请求拦截： API Server 将创建/更新请求发送至 Kyverno 的 Admission Webhook。
- 策略匹配： Webhook 根据请求的资源类型、Namespace、Label 等属性，匹配已加载的 ClusterPolicy/Policy。
- 规则执行： 按顺序执行匹配策略中的 validate、mutate、generate 规则。
- 变更应用： 如果存在 mutate 规则，Webhook 返回修改后的资源 JSON Patch。
- 验证判断： 如果存在 validate 规则，根据
validationFailureAction（Enforce/Audit）决定是否拒绝请求。 - 报告生成： 异步生成 PolicyReport 记录策略执行结果。
灾备场景优势： Kyverno 的 mutate 能力可以在资源创建时自动注入灾备 Sidecar（如 Velero 插件、数据同步代理），generate 能力可以为每个 Namespace 自动创建灾备相关的 NetworkPolicy 和 VolumeSnapshotClass，无需人工干预。