2. Kyverno 架构基础：Admission Controller 模式、Webhook 生命周期、策略引擎核心组件
理解 Kyverno 的架构是进行策略冷启动性能优化与资源配额设计的前提。本章将深入剖析 Kyverno 的运行模式、请求处理流程以及内部核心组件的协作关系，为后续章节的调优实践打下坚实的理论基础。
2.1 Admission Controller 模式：Kubernetes 的策略守门人
Kyverno 本质上是一个运行在 Kubernetes 集群内部的 动态准入控制器（Dynamic Admission Controller）。它通过监听并拦截发往 API Server 的请求，在资源持久化到 etcd 之前执行策略校验与变更。
Kubernetes 的准入控制分为两个阶段：
- Mutating Admission Webhook（变更准入）：允许修改请求对象，例如注入 Sidecar、设置默认标签、修正资源配额等。
- Validating Admission Webhook（验证准入）：仅检查请求对象是否符合策略，不允许修改，例如检查镜像来源、禁止特权容器、验证资源配额上限等。
Kyverno 同时实现了这两种 Webhook，使其既能执行“策略即代码”的校验，也能执行“策略即补丁”的自动修复。
性能关键点： Admission Controller 模式意味着 Kyverno 处于集群请求的同步关键路径上。任何策略处理延迟都会直接增加 API 请求的响应时间，进而影响集群的整体稳定性。冷启动优化正是为了缩短 Kyverno 在首次加载或策略变更后的处理延迟。
2.2 Webhook 生命周期：从注册到调用的完整链路
Kyverno 的 Webhook 生命周期涉及多个组件的协同工作，理解这一链路是定位性能瓶颈的基础。
- Webhook 注册：Kyverno 启动后，会向 API Server 注册
MutatingWebhookConfiguration和ValidatingWebhookConfiguration资源，声明需要拦截的资源类型、操作（CREATE/UPDATE/DELETE）以及回调的 Service 地址。 - 请求拦截：当客户端（kubectl、Controller、Scheduler 等）向 API Server 发送请求时，API Server 根据已注册的 Webhook 配置，将请求封装为
AdmissionReview对象，并发起 HTTPS 回调。 - 策略匹配与执行：Kyverno 的 Webhook Server 接收请求后，根据请求的 Group/Version/Resource（GVR）和操作类型，匹配已加载的策略规则，并执行对应的引擎逻辑。
- 响应返回：Kyverno 将处理结果（允许/拒绝/补丁）封装回
AdmissionReview对象，返回给 API Server。API Server 根据响应决定是否继续处理请求。 - 超时与重试：Kubernetes 默认的 Webhook 超时时间为 30 秒。如果 Kyverno 在超时时间内未响应，API Server 会认为请求失败，并根据
failurePolicy配置（Fail 或 Ignore）决定是否放行请求。
冷启动影响： 在策略冷启动阶段，策略引擎尚未完成初始化或缓存未预热。此时如果 Webhook 超时，可能导致大量请求被拒绝（failurePolicy: Fail）或绕过策略检查（failurePolicy: Ignore），造成生产事故。因此，冷启动性能优化直接关系到 Webhook 生命周期的可靠性。
2.3 策略引擎核心组件
Kyverno 的策略引擎由多个模块化组件构成，每个组件在策略处理链路中承担特定职责。了解这些组件的功能与资源消耗模式，是进行资源配额设计的基础。
| 组件名称 | 核心职责 | 资源消耗特征 | 冷启动影响 |
|---|---|---|---|
| Webhook Server | 接收 AdmissionReview 请求，进行 TLS 验证与请求路由 | CPU 密集（TLS 握手），内存较低 | 高并发下 TLS 握手队列堆积 |
| Policy Cache | 存储已解析的策略规则，提供快速匹配查询 | 内存密集，策略数量与复杂度决定内存占用 | 冷启动时缓存未命中，导致全量策略重新解析 |
| Engine Executor | 执行策略匹配、变量替换、条件评估与补丁生成 | CPU 密集（JMESPath 解析、正则匹配），内存中等 | 首次执行需编译规则，延迟显著增加 |
| Metrics Collector | 收集策略执行延迟、通过/拒绝计数、错误率等指标 | 内存与 CPU 均较低 | 无直接影响，但指标数据丢失影响监控 |
| Leader Election | 多副本部署时选举 Leader，确保 Webhook 配置一致性 | 极低，仅维持租约 | Leader 切换期间可能短暂影响 Webhook 可用性 |
2.4 组件协作与数据流
当一个请求到达 Kyverno 时，上述组件按照以下顺序协作：
- Webhook Server 接收请求，完成 TLS 握手与请求反序列化。
- Policy Cache 根据请求的 GVR 和操作类型，快速检索匹配的策略列表。
- Engine Executor 遍历匹配的策略，执行规则评估。对于 Mutating 策略，生成 JSON Patch 补丁；对于 Validating 策略，返回允许/拒绝决策。
- Metrics Collector 记录本次处理的延迟、结果和错误信息，暴露给 Prometheus 等监控系统。
- Webhook Server 将结果序列化为 AdmissionReview 响应，返回给 API Server。
冷启动性能瓶颈定位： 在策略冷启动场景下，Policy Cache 和 Engine Executor 是主要瓶颈。缓存未命中导致策略重新加载与解析，引擎首次执行需要编译规则，两者共同导致请求处理延迟从微秒级飙升到秒级。后续章节的优化策略将重点围绕这两个组件展开。
2.5 架构设计对资源配额的影响
基于上述架构分析，我们可以总结出资源配额设计的关键考量点：
- Webhook Server 需要足够的 CPU 资源应对 TLS 握手与请求序列化，建议配置 CPU 请求不低于 500m，以应对突发流量。
- Policy Cache 的内存需求与策略数量、规则复杂度成正比。建议为每个 Kyverno 副本预留至少 256Mi 内存用于缓存，并设置内存限制（如 1Gi）防止 OOM。
- Engine Executor 在冷启动阶段需要额外的 CPU 资源用于规则编译。建议在策略变更或部署更新时，临时提高 CPU 配额或使用
initContainers预热缓存。 - Metrics Collector 资源消耗较低，但建议保留足够的存储空间用于指标数据的临时缓冲，避免因指标积压导致内存泄漏。
最佳实践： 在生产环境中，建议为 Kyverno 配置
requests 和 limits 不同的资源配额。requests 设置为稳态运行所需的最小资源，limits 设置为冷启动或突发流量时的上限。同时，结合 HPA（Horizontal Pod Autoscaler）基于 CPU 和内存使用率自动扩缩容，可以有效应对冷启动带来的资源压力。