1. 课程导论：Webhook 超时与 Operator 容量的关系概述

在 Kubernetes 生产环境中，准入控制 Webhook（Admission Webhook）是 Operator 实现资源校验、默认值注入、策略管控的核心拦截点。然而，Webhook 超时设置往往被低估——它不仅是 API 请求的“截止时间”，更是决定 Operator 吞吐能力与集群稳定性的关键杠杆。本章将建立 Webhook 超时与 Operator 容量之间的基本分析框架。

1.1 核心概念：准入控制 Webhook 与 Operator 容量

准入控制 Webhook 是 Kubernetes API Server 在持久化资源对象之前调用的外部 HTTP 回调。Operator 通过注册 MutatingWebhookConfiguration 或 ValidatingWebhookConfiguration 来拦截特定资源的创建、更新或删除操作。

1.2 Webhook 超时如何影响 Operator 容量

Webhook 超时通过以下三条路径直接影响 Operator 的容量表现：

1. 请求生命周期缩短：超时值越小，Operator 必须在更短时间内完成校验/变更逻辑，否则请求被丢弃，Operator 需要处理更多重试流量。
2. 并发窗口压缩：API Server 对每个 Webhook 有并发限制（默认 maxMutatingRequestsInflight 等），超时越短，同一时间窗口内可处理的请求数越少。
3. 重试风暴放大：超时导致的失败请求会被客户端或控制器自动重试，形成“超时→重试→更多超时”的正反馈循环，迅速耗尽 Operator 资源。

1.3 典型容量瓶颈场景

以下三种生产场景最能体现 Webhook 超时与 Operator 容量的强耦合关系：

• 场景 A：大规模集群启动——数百个 Pod 同时创建，Webhook 超时过短导致大量请求被丢弃，Operator 陷入重试风暴，实际吞吐量下降 60% 以上。
• 场景 B：外部依赖慢响应——Operator 在 Webhook 中调用外部 CA 服务签发证书，外部延迟抖动导致超时失败，集群资源创建被阻塞。
• 场景 C：Operator 扩缩容滞后——Webhook 超时设置过长（接近 30s），API Server 侧连接数被占满，新请求无法进入，Operator 无法感知压力上升。

1.4 课程学习路径与收益

本课程将按照以下结构逐步深入 Webhook 超时与 Operator 容量的优化方法：

1.5 本章小结