3. Kyverno 基础架构：Admission Webhook、Policy Engine、Rule 生命周期
在容量规划视角下，理解 Kyverno 的内部架构是评估其资源消耗与性能瓶颈的前提。Kyverno 作为 Kubernetes 原生的策略引擎，其核心运行机制围绕 Admission Webhook、Policy Engine 和 Rule 生命周期 三个关键组件展开。本节将逐一拆解这些组件，并分析它们对集群资源（CPU、内存、API Server 吞吐量）的影响。
3.1 核心架构总览
Kyverno 以 Pod 形式部署在集群中，通常包含一个或多个副本。其工作流程始于 Kubernetes API Server 的准入请求，终于策略的判定与响应。下图展示了 Kyverno 的核心组件及其交互关系：
容量规划提示： 在 Kyverno 架构中，Admission Webhook 是请求入口，其响应时间直接影响 Pod 创建延迟；Policy Engine 是 CPU 密集型组件，规则复杂度与数量决定了单次请求的消耗；Rule 生命周期 管理则影响内存占用与缓存效率。
3.2 Admission Webhook：请求入口与资源消耗
Kyverno 通过注册 MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook 来拦截资源请求。这是 Kyverno 与 API Server 交互的唯一通道，也是容量规划的首要关注点。
3.2.1 Webhook 类型与作用
| Webhook 类型 | 触发时机 | 主要操作 | 对资源的影响 |
|---|---|---|---|
| MutatingWebhook | 资源持久化之前 | 修改资源（注入 Sidecar、添加标签、设置默认值） | 增加 API Server 序列化/反序列化开销；Kyverno 需返回 JSON Patch |
| ValidatingWebhook | 资源持久化之后、存储之前 | 验证资源（检查镜像仓库、禁止特权容器） | 增加 API Server 等待时间；Kyverno 需返回 Allow/Deny 判定 |
3.2.2 容量规划关键指标
- Webhook 超时设置： 默认
30s，但建议根据规则复杂度调整为5s-15s，避免长时间占用 API Server 连接池。 - 失败策略 (failurePolicy)：
Fail或Ignore。在容量不足时，Ignore可避免级联故障，但会降低策略覆盖率。 - 并发请求数： 每个 Kyverno Pod 默认处理
50个并发请求。当集群规模较大（如每秒创建 100+ Pod）时，需增加副本数或调整maxConcurrent参数。
常见陷阱： 如果 Kyverno 响应缓慢，API Server 会累积未完成的准入请求，导致 API Server 自身内存飙升。务必为 Kyverno 设置 资源请求与限制（如 CPU: 500m, Memory: 512Mi），并监控
webhook_duration_seconds 指标。
3.3 Policy Engine：规则匹配与执行引擎
Policy Engine 是 Kyverno 的大脑，负责加载策略、匹配资源、执行规则并生成结果。从容量规划角度看，引擎的 规则匹配算法 和 执行路径 是性能瓶颈的核心。
3.3.1 引擎工作流程
- 策略加载： 从 ConfigMap 或自定义资源 (Policy/ClusterPolicy) 中读取 YAML 定义。
- 资源匹配： 根据
match和exclude规则过滤资源（按 kind、label、namespace 等）。 - 规则执行： 按顺序执行
validate、mutate、generate或verifyImages规则。 - 结果聚合： 将所有规则结果合并为最终的准入响应。
3.3.2 规则类型与性能特征
| 规则类型 | CPU 消耗 | 内存消耗 | 典型场景 |
|---|---|---|---|
| validate | 中 | 低 | 检查 Pod 安全上下文、禁止 hostNetwork |
| mutate | 高 | 中 | 注入 Sidecar、添加资源限制默认值 |
| generate | 低（仅创建时触发） | 低 | 为 Namespace 自动生成 NetworkPolicy |
| verifyImages | 极高 | 高 | 验证镜像签名（需下载并检查 OCI 签名） |
容量规划建议：
verifyImages 规则会引入额外的网络 I/O 和签名验证计算，建议仅在关键命名空间启用，并为其预留独立的 Kyverno 实例或调整资源配额。
3.4 Rule 生命周期：从加载到回收
每条 Kyverno 规则都经历 加载 → 缓存 → 评估 → 报告 → 回收 的完整生命周期。理解这一过程有助于预测内存增长趋势和缓存失效开销。
3.4.1 生命周期阶段详解
3.4.2 生命周期各阶段的资源消耗
| 阶段 | 触发条件 | 主要资源消耗 | 容量规划建议 |
|---|---|---|---|
| 加载 | 策略创建/更新/删除 | CPU（解析 YAML、编译规则） | 避免频繁更新策略；使用 --policyCacheMaxSize 限制缓存大小 |
| 缓存 | 策略加载后 | 内存（存储 AST、正则表达式、变量绑定） | 监控 kyverno_policy_rule_count 指标；预估每条规则约占用 50-200KB 内存 |
| 评估 | 每次准入请求 | CPU（模式匹配、JMESPath 查询、条件判断） | 使用 --maxQueuedRequests 控制队列深度；避免在规则中使用高复杂度正则 |
| 报告 | 评估完成后 | API Server 存储（创建/更新 PolicyReport） | 启用 --reportingInterval 批量上报；设置报告保留天数 |
| 回收 | 策略删除或 Pod 重启 | 内存释放（GC 开销） | 确保 Pod 有足够的 Memory Limit 避免 OOMKill |
最佳实践： 在容量规划测试中，建议使用
kyverno benchmark 命令（或自定义压测脚本）模拟不同规模的规则集和并发请求，观察 Kyverno Pod 的 CPU 和内存曲线。通常，每 100 条规则约增加 50-100MB 内存占用。
3.5 组件协同与容量规划总结
Kyverno 的三个核心组件并非独立运行，而是形成一个完整的请求处理流水线。任何一环的瓶颈都会影响整体性能。下表总结了各组件在容量规划中的关键参数：
| 组件 | 关键配置参数 | 监控指标 | 扩容策略 |
|---|---|---|---|
| Admission Webhook | maxConcurrent, failurePolicy, timeoutSeconds |
webhook_request_duration_seconds, webhook_requests_total |
增加 Pod 副本数；调整 maxConcurrent 至 100-200 |
| Policy Engine | --maxQueuedRequests, --backgroundScanInterval |
policy_execution_duration_seconds, policy_evaluation_count |
拆分规则到多个 Kyverno 实例；使用 --ruleCapacity 限制单实例规则数 |
| Rule 生命周期 | --policyCacheMaxSize, --reportingInterval |
policy_cache_size, policy_report_count |
定期清理缓存和报告；为 Kyverno 设置合适的 Memory Limit |