2. Kyverno 架构基础：组件架构、Admission Review 流程与策略引擎核心模块
理解 Kyverno 的架构是进行冷启动性能优化的前提。本章将拆解 Kyverno 的组件构成、Admission Review 请求的生命周期，以及策略引擎的核心执行模块，为后续链路分析与瓶颈定位奠定基础。
2.1 Kyverno 组件架构
Kyverno 采用 Operator 模式 部署在 Kubernetes 集群内，主要由以下核心组件构成：
| 组件名称 | 部署形态 | 核心职责 |
|---|---|---|
| Admission Controller | Deployment (通常 2 副本) | 接收 API Server 的 AdmissionReview 请求；执行策略匹配与引擎调用；返回准入响应。 |
| Webhook Server | 与 Admission Controller 同 Pod | 注册 Mutating / Validating WebhookConfiguration；处理 TLS 证书；请求路由。 |
| Policy Controller | 与 Admission Controller 同 Pod | 监听 ClusterPolicy / Policy 资源变化；将策略编译为可执行的规则集；维护策略缓存。 |
| Report Controller | Deployment (通常 1 副本) | 生成 PolicyReport / ClusterPolicyReport；处理后台扫描（Background Scan）结果。 |
| Cleanup Controller | Deployment (可选) | 管理基于策略的 TTL 清理规则（CleanupPolicy）。 |
性能关键点： Admission Controller 与 Policy Controller 位于同一 Pod 内，共享本地缓存。冷启动时，Policy Controller 需要从 API Server 全量拉取策略并编译，此过程直接影响首次请求的延迟。
2.2 Admission Review 请求流程
当用户通过 kubectl apply 或 API 调用创建/更新资源时，API Server 会触发 Admission Review 流程。Kyverno 作为动态准入控制器，其处理链路如下：
- 请求拦截： API Server 根据 WebhookConfiguration 规则，将匹配的 AdmissionReview 请求发送至 Kyverno Webhook Server。
- TLS 验证与反序列化： Webhook Server 验证请求签名，将 AdmissionReview 反序列化为内部对象。
- 策略匹配： Admission Controller 根据请求的
kind、apiVersion、operation等字段，查询本地策略缓存，筛选出适用的策略列表。 - 引擎执行： 对每条匹配策略，调用策略引擎执行规则评估（包括 mutate、validate、generate）。
- 响应组装： 汇总所有引擎执行结果，生成 AdmissionResponse（允许/拒绝 + Patch 操作）。
- 返回 API Server： Webhook Server 将响应序列化后返回给 API Server，API Server 根据响应决定是否持久化资源。
冷启动影响： 步骤 3 的策略匹配依赖本地缓存。若缓存未就绪（冷启动），Admission Controller 会回退到直接查询 API Server，增加 1-2 次网络往返，显著提升延迟。
2.3 策略引擎核心模块
策略引擎是 Kyverno 执行规则评估的“大脑”，其内部模块划分如下：
| 模块名称 | 输入 | 输出 | 冷启动影响 |
|---|---|---|---|
| Rule Compiler | 原始 YAML 策略定义 | 编译后的规则对象（AST） | 高：冷启动时需全量编译所有策略 |
| Match/Exclude Evaluator | 请求资源元数据 | 匹配/排除结果（bool） | 低：仅字符串/标签匹配 |
| Precondition Evaluator | 请求资源 + 集群上下文 | 前置条件满足/不满足 | 中：需解析 JMESPath 表达式 |
| Mutation Engine | 原始资源对象 | JSON Patch 操作列表 | 中：需执行 overlay 或 patchStrategicMerge |
| Validation Engine | 原始/变异后资源对象 | 验证通过/拒绝 + 消息 | 中：需执行 pattern 或 anyPattern 匹配 |
| Generation Engine | 请求资源 + 策略定义 | 需创建的附属资源列表 | 低：仅在创建时触发 |
| Context Loader | 外部数据源引用（APICall, ConfigMap, OCI） | 加载后的上下文数据 | 高：冷启动时首次加载可能超时 |
性能陷阱： Context Loader 模块在冷启动时若引用了大量外部数据（如多个 APICall 或 OCI 镜像），会形成串行加载瓶颈。建议在冷启动阶段对 Context 加载设置超时与重试退避策略。
2.4 架构视角的冷启动瓶颈总结
从架构层面看，冷启动数据传输链路的性能瓶颈主要集中在以下三个环节：
- 策略同步与编译（Policy Controller → Rule Compiler）： 冷启动时需全量拉取所有策略并编译，策略数量越多，首次延迟越高。
- 缓存预热（Policy Cache → Admission Controller）： 缓存未就绪前，Admission Controller 无法本地匹配策略，需回退到 API Server 查询。
- 外部数据加载（Context Loader → 外部数据源）： 策略中引用的 ConfigMap、APICall、OCI 镜像等外部数据在冷启动时首次加载，网络延迟与数据量直接影响引擎执行时间。