【kube-apiserver】Admission 链概览：内置插件顺序与 webhook 边界
内容提要
本文介绍Kubernetes v1.30.3中Admission链的机制与排障。请求经AuthN、AuthZ后进入Admission，分Mutating和Validating两阶段，失败即返回错误，不写入etcd。内置插件如NamespaceLifecycle、LimitRanger、ResourceQuota在注册入口装配。Webhook集成有超时和failurePolicy，争议在于fail-open与fail-closed的可用性/安全性权衡。排障时需区分Admission轴与存储问题。
延伸解读
Admission 失败与存储失败的分辨
Admission 链在 AuthZ 之后、etcd 写入之前运行，任何插件或 webhook 拒绝都会导致请求失败且不写入 etcd。排障时，若 Create/Update 返回 4xx 且 etcd 无写入，应优先怀疑 Admission 轴，而非存储问题。错误信息中的关键词（如 exceeded quota、LimitRange、namespace terminating）可快速定位具体插件。
Mutating 与 Validating 的顺序不可颠倒
Admission 固定先执行 Mutating 阶段，再执行 Validating 阶段。Mutating 插件可修改对象，Validating 插件只能通过或拒绝。对象解码和默认值填充发生在 Admission 之前，因此插件看到的是已填充默认值的对象。部分插件（如 ServiceAccount）同时实现两个接口，会在两个阶段被调用。
Webhook 故障时的可用性与安全性权衡
Webhook 的 failurePolicy 决定其不可达时的行为：Fail（fail-closed）拒绝请求，安全性高但影响可用性；Ignore（fail-open）放行请求，可用性高但可能造成策略漏洞。官方建议安全敏感 webhook 使用 Fail 并保证 HA，辅助类 webhook 需评估 Ignore 的影响。工程上，fail-closed 加多副本优于 fail-open 加单副本。
Q&A
Kubernetes中Admission链在请求处理路径中的位置是什么？
Admission链位于AuthN和AuthZ之后、storage.Interface（etcd）持久化之前。请求先经过认证和授权，然后进行对象解码和默认值填充，接着进入Admission阶段（包括Mutating和Validating），最后才写入etcd。
Kubernetes中Mutating和Validating Admission的顺序是怎样的？
Mutating阶段先于Validating阶段执行，顺序不可重排。Mutating插件可以修改对象，而Validating插件只能通过或拒绝请求，不能修改对象。对象schema验证在Mutating完成后、Validating之前执行。
内置Admission插件如NamespaceLifecycle、LimitRanger、ResourceQuota分别有什么作用？
NamespaceLifecycle：在Namespace处于Terminating状态时拒绝在其中创建新对象，但Namespace自身的创建和删除不受影响。LimitRanger：为未显式设置资源请求/限制的Pod或Container填充默认值，并校验资源是否在LimitRange范围内。ResourceQuota：检查Namespace的配额使用量，超限则拒绝请求。
Admission webhook的failurePolicy为Fail和Ignore有什么区别？
failurePolicy为Fail（fail-closed）时，webhook故障会导致请求被拒绝，安全性高但影响可用性；为Ignore（fail-open）时，webhook故障时请求会通过，可用性高但安全变弱。这是可用性与安全性的权衡。
如何区分Admission失败和存储（etcd）失败？
如果请求返回错误但etcd中没有写入任何数据，通常说明失败发生在Admission阶段。例如，错误信息包含'admission webhook denied'、'exceeded quota'、'LimitRange'等，都表明是Admission插件拒绝，而非存储问题。
Admission webhook的超时时间默认是多少？超时后如何处理？
WebhookClientConfig.TimeoutSeconds默认10秒，上限30秒。超时后根据failurePolicy决定请求是否被拒绝：如果failurePolicy为Fail，则请求被拒绝；如果为Ignore，则请求通过。
