准入Webhook失败模式该如何权衡

准入 Webhook 不可用时，是放行还是拒绝？我的判断是：别先争哪种模式“更安全”，先问团队更不能承受哪种后果——未经校验的镜像进入集群，还是故障期间无法创建新 Pod。failurePolicy 的取舍，本质上是在这两种风险之间划边界。

先分清两种失败

我会先把“校验不通过”和“校验服务没能完成判断”分开。镜像未签名、签名身份不可信，属于策略拒绝；Webhook 调用失败，则是校验链路出了问题。Fail 与 Ignore 处理的是后者，不能把 Ignore 理解成允许所有违规镜像。

选择 Fail，意味着无法确认就拒绝，能守住校验边界，但也把准入服务变成了发布和恢复的依赖。选择 Ignore，相关请求可以继续，却会留下未经校验的放行窗口。这不是安全功能的开关，而是故障时由谁承担代价。

看恢复路径，不只看正常发布

我更关心的场景是：业务需要扩容或重建 Pod，准入服务却恰好不可用。已有副本仍在运行，不代表服务就能顺利恢复。对来源约束必须严格执行的工作负载，可以倾向 Fail；对恢复能力更敏感的工作负载，若考虑 Ignore，就要明确接受绕过风险，并保留审计与后续核查。

这种判断应结合规则作用域，而不是全集群一刀切。平台组件、注入边车和业务镜像的信任条件不同，混在一起，只会让一次故障牵连更多对象。

把选择变成可演练的约定

上线前，我会要求演练准入服务不可用时的创建、扩缩容和发布，确认实际影响。同时写清楚谁能降级、何时触发、如何恢复，以及豁免何时到期。

还有个容易混淆的点：策略审计模式不等于调用失败时放行。若 Webhook 已经不可达，仅调整策略模式未必能解除阻断。真正可靠的选择，不是配置里写了哪个值，而是团队能解释放弃了什么，并能在故障中执行对应预案。