Kyverno 架构深度解析：组件、执行流程与交互模型
Kyverno 作为云原生场景下最流行的策略引擎之一，其架构设计围绕 Kubernetes 原生扩展机制展开。理解 Kyverno 的核心组件、策略执行流程以及与 API Server 的交互模型，是进行准入策略移植适配的基础。本章将从这三个维度进行深度拆解。
2.1 核心组件：Webhook、Controller 与 Cache
Kyverno 由三个关键组件构成，它们协同工作以实现策略的声明式管理和实时准入控制。
| 组件 | 职责 | 关键行为 |
|---|---|---|
| Webhook | 拦截 API Server 的准入请求 | 解析 AdmissionReview 请求，调用策略引擎进行匹配与验证，返回 AdmissionResponse |
| Controller | 管理策略与资源的生命周期 | 监听 Policy/ClusterPolicy 资源变化，生成对应的 Webhook 配置；监听资源变更触发后台扫描 |
| Cache | 提供策略与资源的本地缓存 | 维护策略规则索引、已处理资源的校验状态，减少对 API Server 的重复查询 |
架构要点：Webhook 是同步阻塞的，必须快速响应；Controller 是异步的，负责配置同步与后台审计；Cache 是性能保障层，避免每次准入都从 API Server 拉取全量数据。
2.2 策略执行流程：从资源创建到准入决策
当用户通过 kubectl apply 或客户端向 API Server 提交资源时，Kyverno 的准入控制流程如下：
- 请求到达 API Server：API Server 对请求进行身份认证与授权后，进入准入控制阶段。
- MutatingWebhook 拦截：Kyverno 的 Mutating Webhook 被调用，对资源进行默认值注入、标签补全等变更操作。
- 对象变更返回：API Server 将变更后的对象持久化到 etcd，并再次进入准入控制链。
- ValidatingWebhook 拦截：Kyverno 的 Validating Webhook 被调用，对最终对象进行策略校验。
- 策略引擎匹配：Webhook 组件从 Cache 中加载匹配的策略规则，执行
match/exclude条件判断。 - 规则执行与响应：命中策略后，执行
validate/mutate/generate动作，生成 AdmissionResponse 返回给 API Server。 - 最终决策：API Server 根据响应决定允许、拒绝或补丁后允许。
关键时序：Mutating Webhook 在 Validating Webhook 之前执行。这意味着先对资源进行补丁或默认值注入，再对最终状态进行校验。移植适配时需注意策略的执行顺序。
2.3 与 API Server 的交互模型
Kyverno 与 API Server 的交互遵循 Kubernetes 标准的 Webhook 模式，同时通过 Controller 模式实现策略配置的动态管理。
2.3.1 Webhook 注册与动态更新
Kyverno Controller 启动后，会执行以下操作：
- 扫描集群中所有的
Policy和ClusterPolicy资源。 - 根据策略中定义的
match规则，自动生成对应的MutatingWebhookConfiguration和ValidatingWebhookConfiguration。 - 当策略新增、更新或删除时，Controller 自动调整 Webhook 配置，无需手动干预。
2.3.2 请求交互的数据流
一次完整的准入请求交互包含以下数据传递：
| 方向 | 数据内容 | 格式 |
|---|---|---|
| API Server → Webhook | AdmissionReview（包含 Object、OldObject、UserInfo、Operation 等） | JSON |
| Webhook → API Server | AdmissionResponse（包含 Allowed、Patch、Status、Warnings 等） | JSON |
| Webhook → Cache | 策略匹配结果、资源校验状态 | 内部数据结构 |
2.3.3 高可用与故障隔离
Kyverno 的 Webhook 组件通常以 Deployment 形式运行，通过 Service 暴露给 API Server。当 Webhook 不可用时，API Server 的默认行为是 fail-closed（拒绝所有请求），这可能导致集群不可用。生产环境中建议：
- 配置
failurePolicy: Ignore对非关键策略进行降级。 - 为 Webhook 设置
timeoutSeconds避免长时间阻塞。 - 使用 PodDisruptionBudget 保证 Webhook 实例的最小可用数量。
移植适配注意：当从其他策略引擎（如 OPA/Gatekeeper）移植策略时，需要关注 Kyverno 的 Webhook 超时设置（默认 30 秒）。复杂策略如果执行时间过长，可能导致请求超时被拒绝。建议在适配过程中对策略进行性能基准测试。
2.4 组件间协作总结
Kyverno 的架构设计体现了 Kubernetes 原生的扩展哲学：
- Webhook 负责实时准入，是策略执行的“前线”。
- Controller 负责策略配置的声明式管理，是“大脑”。
- Cache 负责数据加速与状态缓存，是“加速器”。