Kubernetes admission webhook调用链规则及自定义配额实现问题咨询

关于Kubernetes准入Webhook相关疑问的解答 #

1. 自定义admission webhook是否会在调用链路的最后执行？

Kubernetes准入流程分为两个串行执行的阶段，先执行变更准入（Mutating）阶段，后执行校验准入（Validating）阶段。所有内置原生准入控制器（如NamespaceLifecycle、ResourceQuota等）会优先于同阶段的自定义webhook执行，同类型的自定义webhook默认没有固定优先级，无法保证你的自定义webhook处于链路最后一位。
即便你将webhook配置在Validating阶段的最后，也无法100%保证资源一定会创建成功——准入流程结束后还有etcd写入环节，可能因为超时、乐观锁冲突等问题写入失败，同样会导致你提前维护的计数与实际资源量不同步。

2. 我们能否自行调整多个admission webhook的执行顺序？

Kubernetes 1.20及以上版本支持自定义同阶段webhook的执行顺序，你可以在MutatingWebhookConfiguration或ValidatingWebhookConfiguration的单条webhook配置中添加order字段，取值范围为-1000~1000，数值越小的webhook越优先执行。
但调整顺序依然不能从根本上解决你遇到的计数不同步问题，只要你在准入阶段就更新计数器，就必然存在后续流程失败导致计数脏的风险。

3. 实现自定义配额管控是否应该采用Kubernetes的其他原生机制？

你当前的设计本身存在逻辑缺陷：准入webhook仅负责请求校验，在资源未真正写入etcd之前，不应该提前更新配额计数器，无论怎么调整执行顺序都无法完全避免计数不同步的问题。
更合理的实现方案可根据你的需求选择：

• 如果是单namespace下的CRD实例数配额管控，直接使用Kubernetes原生ResourceQuota即可，原生机制已经支持自定义CRD的实例数配额统计，不需要自行开发webhook维护计数。
• 如果你的配额逻辑比较复杂（如跨namespace配额、自定义计量规则等），建议采用「准入校验+异步Controller同步」的最终一致方案：准入阶段仅查询当前已成功写入的资源存量，判断新请求是否超限，不会提前更新计数；资源成功写入etcd之后，再由自定义Controller异步同步配额计数，避免不一致问题。

内容的提问来源于stack exchange，提问作者Otor