请求在哪里被拦住，Kyverno 又站在哪里

一句话总结

一次 kubectl apply 在 API 服务器内要经过六个站点：认证 → 授权 → mutating admission → schema 验证 → validating admission → etcd 存储。Kyverno 的 mutate 位于第三个站点，validate 位于第五个。不了解这个顺序，就会被自己的策略拦住。

为什么需要它

在集群中强制执行规则，原本有两种方法。一种是用 RBAC 限制“谁能做什么”，另一种是通过评审由人查看清单。但实际工作中的需求大多介于两者之间。开发者创建 Deployment 本身必须允许，但这个 Deployment 不带资源限制就启动、使用 latest 标签或以 privileged 运行，则必须阻止。RBAC 只看动词和资源种类，不看内容，所以无法表达这种需求。于是 API 服务器在授权之后开放了一个“查看请求内容再做判断”的扩展点，这就是准入 Webhook。

站点有先后顺序也是有原因的。先做认证和授权，是为了不对连身份都不明的请求做繁重的处理。mutating 排在 validating 之前，是因为“先改好再检查”的流程很自然。如果填充默认值的 Webhook 排在检查之后，就没有任何请求能通过。

工作原理

由这个顺序可以直接得出一个实际结论。validate 规则看到的对象，已经是 mutate 规则处理之后的对象。如果同时设置了注入 sidecar 的 mutate 策略和要求所有容器都有资源限制的 validate 策略，被注入的 sidecar 也会成为限制检查的对象。如果注入的规格中没有写限制，部署就会被阻止，而此时日志里打印的是用户根本没写过的容器名称。把资源限制一并写进 sidecar 注入策略，不是偏好，而是要求。

Kyverno 由三个控制器组成，各自的职责不同。

控制器	何时运行	职责
admission	请求到达时实时运行	在 Webhook 中评估 mutate 和 validate 并返回响应
background	周期性运行，以及在出现 UpdateRequest 时运行	扫描现有资源，执行 generate 规则的实际创建与同步
reports	评估结果积累时运行	创建并汇总 PolicyReport / ClusterPolicyReport 对象

三者分开是因为性质不同。admission 必须在毫秒内响应，background 花几分钟也可以，而 reports 写入量很大。如果放在同一个进程里，报告汇总一拖延，部署就会一起被拖慢。generate 规则不在 admission 中直接创建资源，而是留下 UpdateRequest，再由 background 处理，也是同样的原因。

最后是 failurePolicy。默认值是 Fail，意思是如果 Webhook 没能在时限内响应，就拒绝请求。从安全角度看这是正确的默认值，但从可用性角度看，它的含义很沉重。如果设置了用通配符匹配所有资源的策略，所有请求都会经过 Webhook，给整个集群加上延迟税，一旦无法在默认超时内响应，请求就会被拒绝。也就是说，Kyverno 变慢，不是集群变慢，而是集群停摆。把匹配范围缩小到必要的种类和命名空间，不是性能调优，而是可用性工作。Webhook 超时默认值是 10 秒，只允许设置 1 到 30 秒之间的值。

在现场相遇的样子

作者的家庭实验室是由 3 台控制平面节点和 4 台 GPU 工作节点组成的 7 节点集群，CNI 是 Cilium 1.20 eBPF，不使用 kube-proxy。在这里反复印证的教训是：“状态为 Ready 与实际在工作是两个不同的命题”。KubeVirt 的所有组件都是 AllComponentsReady，VM 却起不来，原因是 virt-launcher Pod 规格中遗漏了卷挂载。Gateway API 方面，把 CRD 放在 v1.2 时，控制器以 tlsroutes 和 referencegrants 不是 v1 为由拒绝启动，只好升级到 v1.6.1。

准入策略也有同样的陷阱。策略对象存在且状态看起来正常，并不意味着这条策略真的在处理请求。如果 Webhook 配置没有注册，或者 match 块什么都没选中，策略会好端端地出现在列表中，却什么也不做。而且，什么都不匹配的策略，用肉眼看和运转良好的策略分不出区别。这是本课程会反复强调的诊断原则，后面要学的本地验证习惯就是它的答案。

下一项测验要确认什么

本模块只讲概念。从下一个模块开始，将亲自编写 ClusterPolicy，并把同样的规则也用 Kubernetes 内置的 ValidatingAdmissionPolicy 建立起来，并排比较两种做法。