📚 课程目录第3章 Kubernetes调度机制

3. Kyverno 入门：核心概念与架构解析

本章是 Kyverno 的起点。我们将从“Kyverno 是什么”开始，通过与 OPA/Gatekeeper 的对比明确其定位，最后深入其架构与核心组件。理解这些基础，是后续编写策略、驱动 GitOps 调度优化的前提。

3.1 Kyverno 是什么

Kyverno 是一个为 Kubernetes 设计的策略引擎，由 Nirmata 开源，现为 CNCF 孵化项目。它的核心理念是：策略即 Kubernetes 资源。你无需学习新的 DSL（领域特定语言），只需编写标准的 Kubernetes YAML 资源（ClusterPolicy / Policy）即可定义策略。

  关键特性：
  原生 Kubernetes 资源：策略使用 apiVersion: kyverno.io/v1，通过 kubectl apply 管理，天然适配 GitOps 工作流。
无需新语言：使用 YAML 中的 match、validate、mutate、generate 等字段，学习曲线平缓。
动态准入控制：通过 ValidatingWebhookConfiguration 和 MutatingWebhookConfiguration 拦截资源请求。
资源生成与同步：可根据策略自动生成 Namespace、NetworkPolicy 等资源，并保持同步。

简单来说，Kyverno 让 Kubernetes 管理员能够用“写 YAML”的方式，实现资源校验、默认值注入、配置生成等能力，而无需开发 Admission Webhook 或维护复杂的策略引擎。

3.2 Kyverno vs OPA/Gatekeeper：核心对比

OPA（Open Policy Agent）与 Gatekeeper 是 Kyverno 最常被拿来对比的方案。下表从多个维度进行对比，帮助你理解各自的适用场景。

对比维度	Kyverno	OPA / Gatekeeper
策略定义方式	Kubernetes 原生 YAML（`ClusterPolicy`）	Rego 语言（声明式查询语言）
学习曲线	低（熟悉 K8s YAML 即可）	中高（需学习 Rego 语法与逻辑）
GitOps 友好度	极高（策略本身就是 Git 中的 YAML 文件）	较高（需额外管理 ConstraintTemplate 和 Constraint）
策略能力	校验、变更、生成、清理、图像验证	校验、变更（需配合外部数据）、复杂逻辑查询
性能与扩展性	轻量，原生集成，适合大多数场景	强大，适合复杂策略和大规模集群
社区与生态	CNCF 孵化，社区活跃，策略库丰富	CNCF 毕业，生态成熟，企业级应用广泛

选型建议：如果你的团队以 Kubernetes 原生操作为主，追求 GitOps 原生集成和低学习成本，Kyverno 是更优选择。如果需要处理复杂的跨资源逻辑、数据查询或已有 Rego 投资，OPA/Gatekeeper 依然强大。

3.3 Kyverno 架构与核心组件

Kyverno 以 Pod 形式运行在集群中，通过 Kubernetes 的动态准入控制机制工作。其核心组件包括 Webhook、Policy Controller 和 Report Controller。下图展示了 Kyverno 的整体架构与请求处理流程。

3.3.1 Webhook 组件

Kyverno 在集群中注册了两种类型的 Webhook：

MutatingWebhookConfiguration：在资源持久化到 etcd 之前拦截请求，用于执行 mutate（变更）策略，例如注入 Sidecar、添加标签、设置默认资源限制。
ValidatingWebhookConfiguration：在资源持久化到 etcd 之前拦截请求，用于执行 validate（校验）策略，例如检查镜像来源、禁止特权容器、强制 Pod 安全标准。

Webhook 本身是一个轻量级的 HTTP 服务器，接收来自 API Server 的 AdmissionReview 请求，并将其转发给 Policy Controller 处理。

3.3.2 Policy Controller

Policy Controller 是 Kyverno 的策略执行引擎，负责：

策略加载与缓存：监听 ClusterPolicy 和 Policy 资源的变化，将策略规则加载到内存中。
请求匹配：根据策略中的 match 和 exclude 规则，判断当前请求是否命中某条策略。
策略执行：根据策略类型（validate / mutate / generate / verifyImages）执行对应的逻辑。
结果返回：将执行结果（允许/拒绝/补丁）封装成 AdmissionResponse，通过 Webhook 返回给 API Server。

3.3.3 Report Controller

Report Controller 是一个异步组件，负责生成和管理策略执行报告。它不参与实时准入控制，而是定期或按需生成 PolicyReport 和 ClusterPolicyReport 资源，记录策略的通过、失败、警告等信息。这对于审计、合规性检查和 GitOps 中的策略状态可视化非常有用。

注意：在 GitOps 场景中，Report Controller 生成的报告可以帮助你快速发现集群中不符合策略的资源，但报告本身是异步的，不能替代实时准入控制。建议将策略报告作为 GitOps 流水线中的一个检查环节。

3.4 策略资源模型

Kyverno 的策略资源分为两种作用域：

资源类型	作用域	典型用途
`ClusterPolicy`	集群级别	全局策略，如禁止所有 Namespace 使用 latest 镜像
`Policy`	命名空间级别	特定 Namespace 的策略，如开发环境允许特权容器

一个策略 YAML 的基本结构如下：

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-latest-tag
spec:
  validationFailureAction: Enforce  # Enforce 或 Audit
  rules:
    - name: require-image-tag
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "镜像标签不能为 latest"
        pattern:
          spec:
            containers:
              - image: "!*:latest"

其中 validationFailureAction 字段控制策略的生效模式：

Enforce：严格模式，违反策略的请求会被直接拒绝。
Audit：审计模式，违反策略的请求会被允许，但会在策略报告中记录违规。

实践建议：在 GitOps 工作流中，建议先在 Audit 模式下部署策略，观察对现有资源的影响，确认无误后再切换为 Enforce 模式，避免意外阻断业务。

3.5 本章小结

本章我们建立了对 Kyverno 的基础认知：

Kyverno 是一个原生 Kubernetes 策略引擎，使用 YAML 定义策略，学习成本低。
与 OPA/Gatekeeper 相比，Kyverno 在 GitOps 集成和易用性上具有明显优势。
其架构由 Webhook、Policy Controller 和 Report Controller 组成，通过动态准入控制实现策略执行。
策略资源分为 ClusterPolicy 和 Policy，支持 Enforce 和 Audit 两种模式。