HDUO Lab

深入 Admission Webhook 陷阱排查：全局失败策略引发的 APIServer 死锁与核心组件调度瘫痪实战

作者：

ningniu

在

某次生产环境故障，整个 K8S 集群突然陷入“脑死亡”状态。现象极其诡异：所有现存业务依然能正常响应外部流量，但任何涉及 Pod 创建、销毁或更新的操作全部卡死。业务发布流水线大面积 context deadline exceeded，HPA 扩容失效，甚至连 CoreDNS 的滚动重启都被一直挂在 Pending 状态。

一句话总结根本原因：安全团队为了强制落地 Pod Security Standards (PSS)，部署了一个 OPA Gatekeeper ValidatingWebhook，但犯了防御性编程的大忌——将 failurePolicy 设为 Fail，且未配置 namespaceSelector 豁免系统级命名空间。当 Webhook 后端 Pod 因资源限制触发 OOMKilled 后，APIServer 无法连接 Webhook，导致所有新建 Pod 的请求被无差别拒绝，包括试图拉起 Webhook 自身的 ReplicaSet。这是一个经典的“先有鸡还是先有蛋”的死锁惨案。

案发现场与日志实录

登录 Master 节点，直接抓取 kube-apiserver 的错误日志。满屏的报错直接把矛头指向了 Admission Controller：

# tail -n 100 /var/log/kubernetes/kube-apiserver.log | grep "failed calling webhook"
E0824 14:32:11.123456       1 dispatcher.go:180] failed calling webhook "validation.gatekeeper.sh": failed to call webhook: Post "https://gatekeeper-webhook-service.gatekeeper-system.svc:443/v1/admit?timeout=3s": dial tcp 10.96.45.12:443: connect: connection refused
E0824 14:32:11.125678       1 trace.go:205] Trace[12345678]: "Create *v1.Pod" (started: 2024-08-24 14:32:08.120) (total time: 3.005s):
Trace[12345678]: [3.005s] [3.005s] END
W0824 14:32:11.125789       1 admission.go:149] Failed calling webhook, failing open validation.gatekeeper.sh: failed calling webhook "validation.gatekeeper.sh": failed to call webhook: Post "https://gatekeeper-webhook-service.gatekeeper-system.svc:443/v1/admit?timeout=3s": context deadline exceeded

通过 kubectl get events -A 查看集群事件，发现不仅是业务 Namespace，连 kube-system 里的调度都瘫痪了：

Warning  FailedCreate  replicaset/coredns-74ff55c5b  Error creating: Internal error occurred: failed calling webhook "validation.gatekeeper.sh": failed to call webhook: Post "https://gatekeeper-...": dial tcp 10.96.45.12:443: connect: connection refused

蠢不可及的架构缺陷

排查过程中，我导出了这个 ValidatingWebhookConfiguration 的 YAML。看一眼配置，血压直接拉满：

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: gatekeeper-validating-webhook-configuration
webhooks:
  - name: validation.gatekeeper.sh
    clientConfig:
      service:
        name: gatekeeper-webhook-service
        namespace: gatekeeper-system
        path: /v1/admit
    failurePolicy: Fail # 致命弱点 1
    timeoutSeconds: 30  # 致命弱点 2：超时时间过长拖垮 APIServer 性能
    rules:
      - operations: ["CREATE", "UPDATE"]
        apiGroups: ["*"]
        apiVersions: ["*"]
        resources: ["pods"] # 致命弱点 3：拦截所有 Pod，无差别攻击
    # 缺失 namespaceSelector，完全没有白名单机制

从技术逻辑上讲，为什么这种配置不可原谅？ 安全组件的引入绝对不能以牺牲系统的底层高可用为代价。如果系统都挂了，还要安全有什么用？

  1. failurePolicy: Fail + 无白名单 = 集群自杀按钮 APIServer 在处理资源创建时，会串行执行 Mutating 和 Validating Webhooks。当 failurePolicy 为 Fail 时，意味着只要 Webhook 不响应（无论是因为 Pod 宕机、网络抖动还是 CNI 故障），APIServer 就会硬拒绝该请求。没有 namespaceSelector 豁免 kube-system 和 gatekeeper-system，一旦 Webhook 挂掉，集群将失去修复自身的能力。

  2. 长达 30 秒的超时设置 如果 Webhook 处于半死不活的状态（例如发生网络黑洞但并未拒绝连接），APIServer 的工作线程会被这个调用阻塞整整 30 秒。在高并发调度场景下，这会瞬间耗尽 APIServer 的 goroutine 与连接池，导致整个控制面请求超时（context deadline exceeded），连只读的 kubectl get pods 都会卡顿。

破局与防御性修复策略

第一步：外科手术式自救 系统已经死锁，常规部署手段无效。直接使用原生 API 强删 Webhook 配置，打通 APIServer 的任督二脉：

# 立即解除全局拦截，恢复调度能力
kubectl delete validatingwebhookconfiguration gatekeeper-validating-webhook-configuration
# 观察 Kube-Controller-Manager，等待 ReplicaSet 开始重试拉起 Pod
kubectl get pods -n gatekeeper-system -w

删除配置后，积压的 Pod 创建请求瞬间被释放，集群恢复生机。

第二步：重塑安全架构的“底线” 安全的实施必须遵循“最小爆破半径”原则。我们将配置进行了防御性重构：

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: gatekeeper-validating-webhook-configuration
webhooks:
  - name: validation.gatekeeper.sh
    # 缩短超时时间，保护 APIServer
    timeoutSeconds: 3
    # 核心系统与监控组件降级为 Ignore，或保持 Fail 但通过 selector 严格过滤
    failurePolicy: Fail 
    namespaceSelector:
      matchExpressions:
        # 绝对禁区：严禁拦截系统组件和 Webhook 自身所在的命名空间
        - key: kubernetes.io/metadata.name
          operator: NotIn
          values: ["kube-system", "gatekeeper-system", "monitoring"]
    rules:
      - operations: ["CREATE", "UPDATE"]
        apiGroups: [""]
        apiVersions: ["v1"]
        resources: ["pods"]

第三步：RBAC 最小权限与 PSS 落地正确姿势 排查中还发现该 Webhook 后端被授予了 cluster-admin。这完全背离了 RBAC 最小权限原则。如果 Webhook 被攻破，攻击者可以直接接管集群。 落地 Pod Security Standards (PSS) 时，更好的做法是利用 K8S 1.23+ 内置的 Pod Security Admission，而不是完全依赖第三方的 Webhook。直接在 Namespace 级别打标签：

apiVersion: v1
kind: Namespace
metadata:
  name: app-prod
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

内置的 Admission Controller 跑在 APIServer 进程内，没有网络开销，也不存在因 Webhook 单点故障导致的死锁问题。

排查清单与同类问题速查

  1. APIServer 延迟突增 / 调度卡死：立即检查 kube-apiserver 日志中是否有 failed calling webhook 报错，确认是否为 Admission Webhook 阻塞。

  2. Webhook 隔离性检查：检查所有 ValidatingWebhookConfiguration 和 MutatingWebhookConfiguration，确保配置了 namespaceSelector，且必须豁免 kube-system 与其自身 Namespace。

  3. 超时与降级策略审查：审查所有 Webhook 的 timeoutSeconds（建议设为 1~3s），评估核心链路是否可以将 failurePolicy 设为 Ignore 以防全局雪崩。

  4. Webhook 自身高可用：Webhook 的 Backend 必须配置合理的 requests/limits（避免 OOM）、PodDisruptionBudget（PDB）防止被无意驱逐，并且使用反亲和性（Anti-Affinity）打散部署在多个节点。

更多文章