📚 课程目录第2章 Kyverno基础回顾

2. Kyverno 基础回顾：架构、Policy 与 Rule 概念、准入控制器工作流程

在深入数据传输优化方案之前，必须牢固掌握 Kyverno 的核心基础。Kyverno 是一个为 Kubernetes 设计的策略引擎，它作为动态准入控制器运行，能够验证、变更和生成 Kubernetes 资源。本章将系统回顾其架构、策略模型以及准入控制器的完整工作流程。

2.1 Kyverno 整体架构

Kyverno 采用典型的 Kubernetes 控制器模式，由多个协同工作的组件构成。其核心架构如下图所示：

Kyverno 以 Deployment 形式部署在集群中，通过注册 MutatingWebhookConfiguration 和 ValidatingWebhookConfiguration 来拦截资源请求。其核心组件包括：

组件	职责	说明
Webhook Receiver	接收 API Server 转发的 AdmissionReview 请求	作为 Kyverno 的入口，负责解析请求并分发给 Policy Engine
Policy Engine	匹配策略并调度执行	根据资源类型和操作类型，找到匹配的 Policy 和 Rule
Validate 模块	执行验证逻辑	检查资源是否符合策略要求，返回允许或拒绝
Mutate 模块	执行变更逻辑	在资源持久化前修改其配置，如添加标签或 Sidecar
Generate 模块	生成额外资源	基于源资源创建新的 Kubernetes 资源，如自动创建 Namespace 对应的 NetworkPolicy

架构要点： Kyverno 不存储资源状态，所有策略评估均在内存中完成。这种无状态设计使其易于水平扩展，但也意味着策略变更需要重新加载配置。

2.2 Policy 与 Rule 概念

Kyverno 的策略模型围绕 Policy 和 Rule 两个核心概念构建。一个 Policy 包含一个或多个 Rule，每个 Rule 定义了匹配条件和执行动作。

2.2.1 Policy 类型

Kyverno 支持两种策略作用域：

ClusterPolicy：集群级别，作用于所有 Namespace 中的资源。
Policy：命名空间级别，仅作用于其所在 Namespace 中的资源。

2.2.2 Rule 结构

每个 Rule 由三个核心部分组成：

部分	字段	描述
匹配	`match`	定义规则适用的资源选择条件（如资源类型、标签、命名空间）
排除	`exclude`	定义规则不适用的资源条件，优先级高于 match
动作	`validate` / `mutate` / `generate`	定义匹配后执行的具体操作

以下是一个典型的 Kyverno ClusterPolicy 示例：

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-pod-labels
spec:
  validationFailureAction: Enforce   # 或 Audit
  rules:
  - name: check-for-labels
    match:
      any:
      - resources:
          kinds:
          - Pod
    validate:
      message: "标签 'app.kubernetes.io/name' 是必需的"
      pattern:
        metadata:
          labels:
            app.kubernetes.io/name: "?*"

  关键字段说明：
  validationFailureAction：Enforce 表示拒绝不符合策略的资源；Audit 仅生成报告，不阻止创建。
pattern：使用通配符 ?* 表示标签值必须存在且非空。

2.3 准入控制器工作流程

Kyverno 作为动态准入控制器，其工作流程贯穿 Kubernetes 资源创建的完整生命周期。下图展示了从用户提交请求到资源持久化的完整路径：

完整的准入控制流程分为以下关键步骤：

用户提交：用户通过 kubectl 或 API 调用提交资源 YAML。
API Server 接收：API Server 对请求进行认证和授权，然后构造 AdmissionReview 对象。
Mutating Webhooks：Kyverno 的变更策略在此阶段执行，可以修改资源内容（如注入 Sidecar、添加默认标签）。
对象验证：Kubernetes 内置的 Schema 验证，确保资源结构符合 CRD 定义。
Validating Webhooks：Kyverno 的验证策略在此阶段执行，决定允许或拒绝请求。
持久化：通过所有检查后，资源被写入 etcd 并返回给用户。

性能关键点： Kyverno 在 Mutating 和 Validating 两个阶段都会拦截请求。如果策略数量过多或规则复杂，会显著增加 API Server 的响应延迟。这正是后续章节讨论数据传输优化的核心动机。

2.4 策略执行模式

Kyverno 支持两种策略执行模式，理解它们的差异对于性能调优至关重要：

模式	行为	适用场景	性能影响
Enforce	拒绝不符合策略的资源请求	生产环境安全基线、合规要求	高（每次请求都需要完整评估）
Audit	允许请求通过，但生成策略违反报告	策略测试、灰度验证、历史合规审计	中（评估结果仅记录，不阻塞请求）

优化建议： 在将策略从 Audit 切换到 Enforce 之前，建议先使用 Audit 模式运行一段时间，收集违反数据并评估对现有工作负载的影响。这可以避免因策略过于严格而导致生产事故。