Kyverno 架构基础：组件架构、Webhook 模式与策略引擎工作流
在深入冷启动性能测试之前，必须建立对 Kyverno 架构的精确理解。本章从组件架构、Webhook 模式和策略引擎工作流三个维度，拆解 Kyverno 在 Kubernetes 集群中的运行机制，为后续瓶颈定位提供结构化的知识基础。
2.1 Kyverno 组件架构
Kyverno 采用 单进程多控制器 架构，所有核心功能集成在一个二进制文件中，通过不同的控制器（Controller）处理不同职责。这种设计减少了部署复杂度，但也意味着冷启动时所有控制器同时初始化，资源竞争明显。
| 组件/控制器 | 职责 | 冷启动影响 |
|---|---|---|
| Webhook Controller | 管理 MutatingWebhookConfiguration 和 ValidatingWebhookConfiguration 的注册与更新 | 启动时需同步所有策略，生成 Webhook 规则，延迟较高 |
| Policy Controller | 监听 ClusterPolicy/Policy 资源，编译策略规则为内部 IR（中间表示） | 冷启动时需加载并编译所有已存在的策略，CPU 密集 |
| Report Controller | 生成策略执行报告（PolicyReport / ClusterPolicyReport） | 启动后需回填历史报告，增加 etcd 和 API Server 负载 |
| Background Controller | 执行后台扫描（BackgroundScan），对已有资源进行策略审计 | 冷启动时触发大规模扫描，可能造成资源洪峰 |
| Generate Controller | 处理 generate 规则，自动创建或更新下游资源 | 启动时需 reconcile 所有 generate 资源，增加 API 调用量 |
下图展示了 Kyverno 的组件关系与数据流：
2.2 Webhook 模式
Kyverno 通过 Kubernetes 的 动态准入控制（Dynamic Admission Control） 机制工作，本质上是注册 MutatingWebhookConfiguration 和 ValidatingWebhookConfiguration 资源，拦截 API 请求。理解 Webhook 模式是分析冷启动性能瓶颈的前提。
2.2.1 两种 Webhook 类型
| Webhook 类型 | 拦截阶段 | 作用 | 冷启动影响 |
|---|---|---|---|
| MutatingWebhook | Admission 请求的 Mutating 阶段 | 修改资源（注入 sidecar、添加标签、设置默认值） | 需先完成所有 mutate 策略的编译和缓存，否则请求超时 |
| ValidatingWebhook | Admission 请求的 Validating 阶段 | 验证资源（检查合规性、拒绝违规请求） | 冷启动时若策略未就绪，可能误拒绝合法请求 |
2.2.2 Webhook 注册与路由
Kyverno 启动时，Webhook Controller 会执行以下步骤：
- 读取所有 ClusterPolicy 和 Policy：从 API Server 获取当前集群中所有策略资源。
- 按规则类型分组：将策略中的规则按 mutate、validate、generate 分类，生成 Webhook 规则列表。
- 计算匹配资源：根据策略的
spec.rules.match字段，确定每个 Webhook 需要拦截的资源类型（如 Pod、Deployment、Namespace）。 - 注册 Webhook 配置：创建或更新 MutatingWebhookConfiguration 和 ValidatingWebhookConfiguration 对象，设置
clientConfig.service指向 Kyverno Service。 - 设置 failurePolicy：默认
Fail，冷启动期间若 Kyverno 未就绪，API Server 会拒绝所有匹配的请求。
下图展示了 Webhook 请求的完整路径：
2.3 策略引擎工作流
当一个 AdmissionReview 请求到达 Kyverno Pod 后，策略引擎按照以下工作流处理：
- 请求接收与解析：Webhook Server 接收 HTTP 请求，解析 AdmissionReview 对象，提取资源类型、名称、命名空间、操作类型（CREATE/UPDATE/DELETE）。
- 策略匹配：遍历所有已加载的策略，根据
spec.rules.match和spec.rules.exclude判断当前请求是否命中策略。 - 规则执行：对命中的策略，按优先级顺序执行规则：
- Mutate 规则：执行 JSON Patch 操作，修改资源对象。
- Validate 规则：执行条件检查（如 pattern、anyPattern、deny），返回允许或拒绝。
- Generate 规则：在后台触发资源生成（不阻塞当前请求）。
- 响应组装：将执行结果封装为 AdmissionReview 响应，设置
allowed、patch、status字段。 - 返回 API Server：HTTP 200 响应返回给 API Server，API Server 根据响应决定是否继续处理请求。
2.3.1 策略编译与缓存机制
Kyverno 使用 两级缓存 来加速策略执行：
| 缓存层级 | 存储内容 | 冷启动状态 |
|---|---|---|
| 一级缓存（内存） | 已编译的策略 IR（中间表示），包括 match/exclude 条件、规则体 | 启动时为空，需逐策略编译填充 |
| 二级缓存（LRU） | 最近执行的 AdmissionReview 请求的匹配结果 | 启动时为空，需通过实际请求预热 |
冷启动时，一级缓存需要从零开始构建。如果集群中存在大量策略（例如 100+），Policy Controller 需要逐个读取、解析、编译，这个过程是 CPU 密集型的，且在此期间所有 Webhook 请求都会经历完整的编译路径。
2.3.2 规则执行优先级
Kyverno 支持在策略中设置 spec.rules.match 的 order 字段，控制规则执行顺序。默认情况下，规则按以下优先级执行：
- Mutate 规则：先执行，因为修改后的资源可能影响后续验证结果。
- Validate 规则：后执行，基于 mutate 后的资源进行验证。
- Generate 规则：异步执行，不阻塞当前请求。
冷启动时，如果 mutate 规则执行缓慢，会直接阻塞 validate 规则的执行，导致整个请求的响应时间（RT）增加。在性能测试中，需要分别测量 mutate 和 validate 的耗时，定位具体瓶颈。
--admission-webhook-benchmark 模式（如果 Kyverno 版本支持）或通过 Prometheus 指标 kyverno_admission_review_duration_seconds 按规则类型拆分，精确分析每个阶段的耗时分布。