mutatingwebhook服务响应超时导致pod卡在pending或报internal error，需按顺序排查：事件错误→webhook配置→服务状态→网络连通性→处理耗时→临时绕过。
当你执行 kubectl apply -f pod.yaml 后 Pod 卡在 Pending 或直接报 Internal error occurred: failed calling webhook "xxx"，且事件中明确出现 context deadline exceeded 或 i/o timeout，说明 MutatingWebhook 服务响应超时，已阻断 Pod 创建流程。
确认超时是否真实发生
第一步：查看 Pod 创建事件中的原始错误信息。
执行 kubectl describe pod <pod-name> -n <namespace></namespace></pod-name>，在 Events 区域定位到类似以下内容：FailedCreate: Error from server (InternalError): failed calling webhook "mutate-pod.example.com": context deadline exceeded。
⚠️ 注意：这个错误不是 Webhook 返回的业务拒绝（如 Forbidden），而是 API Server 根本没等到 Webhook 回复就主动放弃——这是典型的网络或服务不可达问题。
第二步：提取 Webhook 配置中的调用地址与路径。
运行 kubectl get mutatingwebhookconfiguration <webhook-name> -o yaml</webhook-name>，重点检查 webhooks[*].clientConfig.service 下的 namespace、name、path 和 port；若使用 url 字段，则跳过服务发现环节，直接验证该 URL 是否可访问。
第三步：确认 Webhook 服务是否在目标命名空间中正常运行。
执行 kubectl get pods -n <webhook-namespace> | grep <webhook-service-name></webhook-service-name></webhook-namespace>，检查 Pod 状态是否为 Running 且 READY 列为 1/1。如果 Pod 处于 CrashLoopBackOff 或 Pending，后续所有排查都失去意义——先解决服务自身启动问题。
验证 Webhook 服务端口与 TLS 连通性
方法一：从 API Server 所在节点直连 Webhook 服务（最贴近真实调用路径）
登录任意一台控制平面节点（通常是 master 节点），执行：curl -v --insecure https://<webhook-service-name>.<webhook-namespace>.svc:443<path></path></webhook-namespace></webhook-service-name>。
其中 <path></path> 必须与 MutatingWebhookConfiguration 中定义的完全一致（例如 /mutate-v1-pod），且必须以 / 开头；不带 --insecure 会因证书校验失败而中断，这不是问题本身，只是调试手段。
方法二：在集群内起一个临时调试 Pod，模拟 API Server 发起调用
运行：kubectl run debug-curl --image=curlimages/curl -it --rm --restart=Never -- sh，进入后执行：curl -v -k https://<webhook-service-name>.<webhook-namespace>.svc.cluster.local:<port><path></path></port></webhook-namespace></webhook-service-name>。
✅ 成功返回 HTTP 200 + JSON 响应体（含 apiVersion: admission.k8s.io/v1）才表示服务可达、路径正确、TLS 终止配置无误。
【关键前提】 Webhook 服务必须监听在 0.0.0.0:<port></port>，不能只监听 127.0.0.1 或 localhost；否则集群内其他节点（包括 API Server）无法建立 TCP 连接。
检查 Webhook 服务的准入逻辑耗时
第一步：进入 Webhook 服务 Pod，查看其日志实时输出。
执行 kubectl logs -f <webhook-pod-name> -n <webhook-namespace></webhook-namespace></webhook-pod-name>，然后立即在另一终端触发一次 Pod 创建（kubectl apply -f test-pod.yaml）。观察日志中是否有请求进入记录、处理开始时间戳、响应写出时间戳。
第二步：确认业务逻辑是否引入了同步阻塞操作。
常见高危行为包括：
• 调用外部 HTTP 接口且未设超时（如查询数据库、调第三方鉴权服务）；
• 在 handler 中执行文件 I/O 或长循环计算；
• 使用了未配置连接池的 HTTP 客户端，导致并发请求排队等待连接。
第三步：强制限制单次请求处理时长。
在 Webhook 代码中，所有 admission handler 函数入口处添加上下文超时：ctx, cancel := context.WithTimeout(r.Context(), 2*time.Second)，并在 defer 中调用 cancel()；所有下游调用必须使用该 ctx。Kubernetes 默认给予 Webhook 最多 30 秒，但生产环境建议将业务逻辑压到 2 秒内完成，避免触发 API Server 的默认 30 秒 deadline。
绕过 Webhook 并临时恢复 Pod 创建
方法一：对特定命名空间禁用自动注入（推荐用于快速恢复）
执行 kubectl label namespace <target-namespace> admission.example.com/enabled- -</target-namespace>（假设 Webhook 通过 namespaceSelector 匹配），然后重新 apply Pod。该操作仅影响目标命名空间，不影响其他命名空间的策略生效。
方法二：临时修改 MutatingWebhookConfiguration 的 failurePolicy
运行 kubectl edit mutatingwebhookconfiguration <webhook-name></webhook-name>，将 failurePolicy: Fail 改为 failurePolicy: Ignore。⚠️ 此操作会使所有匹配请求跳过该 Webhook，**策略失效风险极高，仅限紧急排障，修复后必须立即改回 Fail**。
方法三：删除 Webhook 配置（最后手段）
执行 kubectl delete mutatingwebhookconfiguration <webhook-name></webhook-name>。此操作会彻底移除该 Webhook 的全局拦截能力，适用于 Webhook 服务已崩溃且短期内无法修复的场景。
