3. Kyverno 基础架构：组件、工作流程与对比

本章深入剖析 Kyverno 的策略引擎核心。理解其内部组件、请求处理流程以及与业界主流方案 OPA/Gatekeeper 的差异，是后续在 GitOps 架构中正确落地 Kyverno 的前提。我们将从三个维度展开：组件职责、端到端工作流、以及关键对比分析。

3.1 核心组件架构

Kyverno 以 Kubernetes 原生方式运行，其架构由三个主要组件构成，它们协同工作以实现策略的声明式管理和动态执行。

3.1.1 组件职责详解

3.2 工作流程：从策略定义到执行

Kyverno 的工作流程分为两个主要阶段：策略加载与编译阶段 和 资源请求处理阶段。理解这两个阶段有助于排查策略未生效或误拦截问题。

3.2.1 策略加载与编译阶段

1. 策略创建： 用户通过 kubectl apply 创建 ClusterPolicy 或 Policy 资源。
2. 策略监听： Policy Controller 通过 Informer 机制监听 CRD 变化。
3. 规则编译： 将 YAML 中的 match、exclude、validate、mutate、generate 规则编译为内部 AST（抽象语法树）。
4. Webhook 注册： Admission Controller 根据策略的 match 规则，自动更新 Webhook 配置，决定拦截哪些资源类型和操作。

3.2.2 资源请求处理阶段

1. 请求发起： 用户或控制器向 kube-apiserver 发送资源创建/更新/删除请求。
2. 请求拦截： kube-apiserver 根据注册的 Webhook 配置，将请求封装为 AdmissionReview 对象，发送给 Kyverno Webhook Server。
3. 策略匹配： Webhook Server 根据请求的资源类型、命名空间、操作类型，匹配已编译的策略规则。
4. 策略执行：
   • Mutating 策略： 修改请求中的资源对象（如注入 Sidecar、添加标签）。
   • Validating 策略： 验证资源对象是否符合规则，返回允许或拒绝。
   • Generate 策略： 在后台创建关联资源（如自动创建 NetworkPolicy）。
5. 响应返回： Webhook Server 将处理结果（允许/拒绝/补丁）封装为 AdmissionReview 响应，返回给 kube-apiserver。
6. 报告生成： Report Controller 异步生成 PolicyReport，记录本次策略执行结果。

3.3 Kyverno 与 OPA/Gatekeeper 对比

OPA（Open Policy Agent）结合 Gatekeeper 是 Kubernetes 生态中另一主流的策略引擎方案。两者在设计哲学、策略语言、集成方式上存在显著差异。下表从多个关键维度进行对比，帮助团队根据自身场景做出技术选型。

3.3.1 策略语言对比示例

以下展示同一个策略（要求 Deployment 必须设置 resources.limits.cpu）在两种引擎中的定义差异。

Kyverno (YAML):

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-cpu-limits
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-cpu-limits
    match:
      any:
      - resources:
          kinds:
          - Deployment
    validate:
      message: "Deployment 必须设置 CPU limits"
      pattern:
        spec:
          template:
            spec:
              containers:
              - resources:
                  limits:
                    cpu: "? *"

OPA / Gatekeeper (Rego):

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: k8srequiredlimits
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredLimits
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredlimits
        violation[{"msg": msg}] {
          container := input.review.object.spec.template.spec.containers[_]
          not container.resources.limits.cpu
          msg := sprintf("容器 %v 必须设置 CPU limits", [container.name])
        }
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLimits
metadata:
  name: require-cpu-limits
spec:
  match:
    kinds:
      - apiGroups: ["apps"]
        kinds: ["Deployment"]