2. Kyverno 架构基础：Admission Controller 工作流、Webhook 与缓存的关系、策略引擎核心组件

2.1 Admission Controller 工作流：从请求到决策

Kubernetes API Server 在持久化任何资源（Pod、Service、Deployment 等）之前，会依次调用注册的 Admission Controller。Kyverno 作为 动态准入 Webhook，在 Mutating 和 Validating 两个阶段介入，形成“请求 → 变更 → 校验 → 存储”的完整链路。

关键路径： 用户执行 kubectl apply -f pod.yaml → API Server 认证/授权 → MutatingWebhookConfiguration 匹配 → Kyverno 执行 mutate 策略 → 返回补丁 → API Server 合并请求 → ValidatingWebhookConfiguration 匹配 → Kyverno 执行 validate 策略 → 返回允许/拒绝 → 最终写入 etcd。
Kyverno Admission Controller 工作流 kubectl apply API Server Mutating Webhook Validating Webhook etcd 存储 拒绝/补丁返回 工作流说明 1. 用户提交资源清单到 API Server。 2. API Server 根据 MutatingWebhookConfiguration 调用 Kyverno 的 mutate 端点。 3. Kyverno 执行 mutate 策略，返回 JSON Patch 给 API Server。 4. API Server 应用补丁后，根据 ValidatingWebhookConfiguration 调用 Kyverno 的 validate 端点。 5. Kyverno 执行 validate 策略，返回 Allowed 或 Denied 给 API Server。

2.2 Webhook 与缓存的关系：为什么缓存命中如此重要

Kyverno 在启动时从 ConfigMap 或 CRD 加载所有策略，并在内存中构建策略缓存。当 Webhook 请求到达时，Kyverno 优先查询本地缓存，而不是每次都从 etcd 重新读取策略。缓存命中率直接影响请求延迟和 API Server 压力。

组件 缓存内容 更新机制 缓存失效影响
策略缓存 ClusterPolicy / Policy 对象 Informer Watch 事件驱动 策略变更延迟生效，可能误判
Webhook 配置缓存 MutatingWebhookConfiguration / ValidatingWebhookConfiguration 启动时加载 + 定时同步 Webhook 注册丢失，请求绕过 Kyverno
资源缓存 已处理的 AdmissionReview 请求摘要 LRU 淘汰 + TTL 过期 重复请求导致重复策略计算
Kubernetes 资源索引 Namespace、Pod、Service 等关联资源 Informer 同步 策略中引用资源查找失败
巡检要点： 缓存命中率低于 95% 时，应检查 Kyverno 的 --cacheResyncPeriod 参数（默认 15 分钟）是否过长，以及 Informer 是否因 RBAC 权限不足而无法同步资源。

2.3 策略引擎核心组件：从策略定义到执行

Kyverno 的策略引擎由四个核心模块组成，它们协同完成策略的解析、匹配、执行和报告。

Kyverno 策略引擎核心组件 策略定义层 (ClusterPolicy / Policy) 规则引擎 match/exclude 匹配 变更引擎 mutate 策略执行 校验引擎 validate 策略执行 生成引擎 generate 资源生成 策略缓存层 策略对象缓存 | Webhook 配置缓存 | 资源索引缓存 | AdmissionReview 摘要缓存 报告与审计层 PolicyReport | ClusterPolicyReport | 后台扫描结果 | 事件日志

2.4 核心组件职责与交互

组件 职责 与缓存的关系 故障排查关注点
规则引擎 解析策略的 match 和 exclude 条件，判断当前请求是否命中策略 依赖策略缓存获取最新规则；资源索引缓存用于匹配 Namespace 标签等 缓存未更新导致策略匹配失效；match 条件过于宽泛导致性能下降
变更引擎 执行 mutate 策略，生成 JSON Patch 补丁 依赖策略缓存；补丁模板中引用的 ConfigMap/Secret 来自资源缓存 缓存中 ConfigMap 过期导致补丁内容错误；补丁过大导致 API Server 拒绝
校验引擎 执行 validate 策略，返回 allow/deny 决策 依赖策略缓存；deny 条件中的变量来自资源缓存 缓存不一致导致误判（允许本应拒绝的资源）；变量解析失败导致策略跳过
生成引擎 执行 generate 策略，在资源创建时自动生成关联资源（如 NetworkPolicy） 依赖策略缓存；生成模板中的变量来自资源缓存 缓存未同步导致生成延迟或重复生成；生成资源与已有资源冲突
策略缓存层 维护所有策略对象、Webhook 配置、资源索引的内存缓存 通过 Informer Watch 与 etcd 保持最终一致 Informer 断开导致缓存停滞；内存压力导致 LRU 淘汰频繁
报告与审计层 生成 PolicyReport 和 ClusterPolicyReport，记录策略执行结果 从缓存读取策略名称和匹配结果；写入报告时直接调用 API Server 报告写入失败导致审计缺失；报告数量过多导致 etcd 存储压力

2.5 缓存命中巡检的关键指标

在后续章节的故障排查实践中，你将频繁使用以下指标定位缓存问题。建议在 Prometheus 中配置告警规则。

  • kyverno_admission_requests_total：总请求数，按策略和操作类型（mutate/validate）区分。
  • kyverno_admission_latency_seconds：请求处理延迟，缓存命中时通常 < 10ms，缓存未命中时可能 > 100ms。
  • kyverno_cache_hit_ratio：策略缓存命中率，低于 0.95 应触发告警。
  • kyverno_informer_sync_failures_total：Informer 同步失败次数，持续增长表示缓存可能停滞。
  • kyverno_policy_execution_duration_seconds：策略执行耗时，缓存未命中时该指标会显著升高。
常见陷阱： 当 Kyverno 重启或 Leader 选举切换时，缓存会完全清空并重新构建。在此期间（通常 30-60 秒），所有 Webhook 请求都会直接查询 etcd，导致延迟飙升。生产环境应配置至少 2 个 Kyverno 副本，并启用 --replicas=2 参数减少重启影响。
← 上一章 📖 返回目录 下一章 →