2. Kyverno 架构解析：核心组件与策略执行流程

Kyverno 作为云原生策略引擎，其架构围绕 Kubernetes 动态准入控制机制设计。理解其核心组件与策略执行流程，是诊断冷启动瓶颈的前提。本章将拆解 Kyverno 的三个核心组件——Webhook、Controller 和 Cache，并梳理一条请求从触发到策略生效的完整路径。

2.1 核心组件总览

Kyverno 采用微服务架构，主要包含以下三个关键组件，它们协同工作以实现策略的加载、匹配与执行。

2.2 组件交互架构图

下图展示了 Kyverno 核心组件之间的交互关系，以及它们如何与 Kubernetes API Server 协同工作。

2.3 Webhook 组件详解

Webhook 是 Kyverno 与 Kubernetes API Server 交互的桥梁。它通过注册 MutatingWebhookConfiguration 和 ValidatingWebhookConfiguration 来拦截资源请求。

• Mutating Webhook：在资源持久化之前执行，用于修改资源（如注入 Sidecar、添加标签）。
• Validating Webhook：在资源持久化之后执行，用于验证资源是否符合策略（如检查镜像来源、禁止特权容器）。
• 故障模式：Webhook 的 failurePolicy 可设置为 Fail 或 Ignore。冷启动时，如果 Webhook 响应超时，API Server 会根据此策略决定是否允许请求通过。

2.4 Controller 组件详解

Controller 是 Kyverno 的大脑，负责策略的生命周期管理。它包含多个子控制器，每个控制器专注于不同的任务。

2.5 Cache 组件详解

Cache 是 Kyverno 性能的核心。它基于 Kubernetes Informer 机制，维护策略定义、资源上下文和集群状态的本地副本。

• 缓存内容：策略定义（Policy/ClusterPolicy）、资源上下文（Namespace、Pod、Deployment 等）、集群状态（节点、CRD 等）。
• 缓存更新：Informer 通过 Watch API 监听资源变化，增量更新缓存。
• 冷启动问题：Pod 重启后，缓存为空。Webhook 处理请求时，如果缓存中缺少策略或上下文，必须回退到 API Server 查询，导致延迟从微秒级飙升到毫秒级甚至秒级。

2.6 策略执行流程

一条资源请求从触发到策略生效，经历以下完整流程。理解此流程有助于定位冷启动瓶颈。

1. 请求触发：用户或控制器向 API Server 发送资源请求（如 kubectl apply -f pod.yaml）。
2. Webhook 拦截：API Server 根据注册的 Webhook 配置，将请求转发给 Kyverno Webhook 服务。
3. 策略匹配：Webhook 从 Cache 中查询匹配的策略。如果缓存未命中，回退到 API Server 查询。
4. 上下文准备：Webhook 从 Cache 中获取资源上下文（如 Namespace 标签、集群配置）。如果缓存未命中，回退到 API Server 查询。
5. 策略评估：Kyverno 引擎执行策略规则（如验证、突变、生成）。
6. 结果返回：Webhook 将评估结果（允许/拒绝/突变）返回给 API Server。
7. 资源持久化：API Server 根据 Webhook 结果决定是否持久化资源。

2.7 策略执行流程图

下图展示了策略执行的完整流程，并标注了冷启动期间可能出现的瓶颈点。

2.8 冷启动瓶颈总结

基于上述架构分析，冷启动阶段的主要瓶颈集中在以下三个环节：