2. Kyverno 架构解析:核心组件、Webhook 机制与策略引擎工作流程

Kyverno 是一个为 Kubernetes 设计的策略引擎,其架构围绕 动态准入控制 和 策略即代码 的理念构建。理解其核心组件、Webhook 交互机制以及策略引擎的内部工作流程,是进行策略审计与集群合规巡检的基础。本章将深入解析这三部分,帮助您建立完整的架构认知。

2.1 核心组件与职责

Kyverno 采用微服务架构,主要由以下四个核心组件构成,它们协同工作以实现策略的声明、执行与报告。

组件名称 部署形态 核心职责
Kyverno Admission Controller Deployment (通常 2 副本) 接收 Kubernetes API Server 的准入 Webhook 请求;调用策略引擎进行匹配与验证;生成准入响应(允许/拒绝/补丁)。
Kyverno Reports Controller Deployment (通常 1 副本) 管理 ClusterPolicyReport 和 PolicyReport 资源;定期对集群中已有资源进行后台扫描,生成合规审计结果。
Kyverno Background Controller Deployment (通常 1 副本) 处理定时任务(如策略后台扫描);管理 Generate 规则的资源生成;处理 MutateExisting 规则的资源更新。
Kyverno Cleanup Controller Deployment (可选) 根据 CleanupPolicy 规则,在指定时间或条件下自动清理集群中的资源(如过期的 Pod、旧的 Job)。
架构要点: Admission Controller 是策略执行的“实时关卡”,而 Reports Controller 是“定期巡检员”。两者结合,既保证了新资源创建时的即时合规,也覆盖了存量资源的持续审计。

2.2 Webhook 机制:策略执行的入口

Kyverno 通过 Kubernetes 的 动态准入控制(Dynamic Admission Control) 机制拦截资源请求。它在集群中注册了两种类型的 Webhook 配置:ValidatingWebhookConfiguration 和 MutatingWebhookConfiguration。

下图展示了 Kyverno 如何通过 Webhook 与 API Server 交互,实现策略的实时执行。

Kyverno Webhook 交互流程 Kyverno Webhook 交互流程 kubectl / 客户端 Kubernetes API Server Webhook 配置 Kyverno Admission Controller etcd (持久化) 1. 创建/更新资源 2. 匹配 Webhook 3. AdmissionReview 4. 响应 (允许/拒绝) 5. 写入 etcd 6. 返回结果给客户端 流程说明: • 步骤 1-2:客户端发起请求,API Server 根据注册的 Webhook 配置(Mutating/Validating)决定是否调用 Kyverno。 • 步骤 3-4:Kyverno 接收 AdmissionReview 请求,执行策略引擎,返回 AdmissionResponse。 • 步骤 5-6:API Server 根据响应决定是否将资源写入 etcd,并最终返回结果给客户端。
Webhook 类型说明:
  • MutatingWebhookConfiguration: 用于执行 mutate 规则,在资源被持久化之前对其进行修改(如注入 Sidecar、添加标签)。
  • ValidatingWebhookConfiguration: 用于执行 validate 规则,决定是否允许资源请求(如检查镜像仓库、禁止特权容器)。
Kyverno 会优先处理 mutate 规则,再处理 validate 规则,确保资源在被验证前已经过必要的修改。

2.3 策略引擎工作流程

策略引擎是 Kyverno 的核心决策模块。当 Admission Controller 接收到一个 AdmissionReview 请求时,引擎会按照以下标准化流程进行处理。

下图展示了从策略匹配到最终响应的完整内部工作流程。

Kyverno 策略引擎工作流程 策略引擎工作流程 1. 接收 AdmissionReview 2. 策略匹配与过滤 3. 规则执行 4a. Mutate 规则 4b. Validate 规则 4c. Generate 规则 5. 生成 AdmissionResponse

2.4 规则执行细节

在策略引擎的“规则执行”阶段,Kyverno 会根据规则的 match 和 exclude 条件,对资源进行精细化的处理。以下是三种规则类型的执行细节对比:

规则类型 执行时机 核心行为 典型场景
Mutate 资源持久化之前 通过 JSON Patch (RFC 6902) 或 Strategic Merge Patch 修改资源请求。 自动注入 Istio Sidecar、添加默认标签/注解、设置资源配额默认值。
Validate Mutate 之后,持久化之前 使用 anyPattern 或 deny 块定义验证条件;支持 CEL (Common Expression Language) 表达式。 禁止使用 latest 镜像标签、强制 Pod 设置 readOnlyRootFilesystem、检查 Ingress 主机名唯一性。
Generate 资源创建时或后台定时触发 根据源资源(如 Namespace)创建或同步目标资源(如 NetworkPolicy、RoleBinding)。 为每个新 Namespace 自动创建默认的 NetworkPolicy、创建对应的 ServiceAccount 和 RBAC 绑定。
重要提示: Generate 规则在准入阶段仅触发“生成请求”,实际的资源创建由 Background Controller 异步完成。这意味着 Generate 规则不会阻塞资源创建的原始请求,但目标资源的创建可能会有短暂延迟。

2.5 策略审计与报告生成

除了实时准入控制,Kyverno 还通过 Reports Controller 提供 后台扫描 能力。该组件会定期遍历集群中的资源,重新评估所有适用的策略,并生成 PolicyReport 或 ClusterPolicyReport 资源。

这些报告资源包含了每个策略对每个资源的详细审计结果,包括:

  • pass: 资源符合策略要求。
  • fail: 资源违反策略要求。
  • warn: 策略配置为警告模式,不强制拒绝。
  • error: 策略引擎在执行过程中遇到内部错误。

通过分析这些报告,运维人员可以清晰地了解集群的合规状态,并针对违规资源进行修复。