3. Mutating 与 Validating Webhook：两种 Webhook 的区别、调用顺序、典型应用场景

Kubernetes 准入控制（Admission Control）中的 Webhook 分为 MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook 两种类型。它们在 API 请求持久化之前介入，但职责、调用顺序和典型用途截然不同。理解两者的差异是编写可靠 Webhook 的基础，也是校准存储版本漂移的关键前提。

3.1 核心职责对比

3.2 调用顺序与执行流程

在 Kubernetes API Server 处理一个创建、更新或删除请求时，Webhook 的调用顺序是固定的：

1. 认证与授权（非 Webhook 阶段）
2. Mutating Webhooks（按配置顺序执行）
3. 对象 Schema 校验（内置校验）
4. Validating Webhooks（按配置顺序执行）
5. 持久化到 etcd

这种顺序设计有明确的工程考量：先让 Mutating Webhook 修改对象（如注入 Sidecar、设置默认值），再让 Validating Webhook 对修改后的完整对象进行校验。如果顺序颠倒，Validating Webhook 校验的将是一个不完整的对象，导致误判。

3.3 典型应用场景

3.3.1 Mutating Webhook：注入 Sidecar

最经典的 Mutating Webhook 场景是 Sidecar 注入，例如 Istio 的 sidecar-injector。当用户创建 Pod 时，Webhook 拦截请求，自动向 Pod 的 spec.containers 中添加一个 Envoy 代理容器，并挂载必要的 Volume。

// 注入 Sidecar 的 JSON Patch 示例
[
  {
    "op": "add",
    "path": "/spec/containers/-",
    "value": {
      "name": "istio-proxy",
      "image": "istio/proxyv2:1.18.0",
      "args": ["proxy", "sidecar"],
      "ports": [
        { "containerPort": 15090, "protocol": "TCP" }
      ]
    }
  },
  {
    "op": "add",
    "path": "/spec/volumes/-",
    "value": {
      "name": "istio-envoy",
      "emptyDir": {}
    }
  }
]

3.3.2 Validating Webhook：校验规则

Validating Webhook 用于执行 不可修改的校验逻辑，例如：

• 资源配额校验：检查 Namespace 中 Deployment 的总副本数是否超过限制。
• 安全策略校验：禁止容器以 root 用户运行，或禁止使用 hostNetwork。
• 存储版本兼容性校验：检查请求中的资源版本是否与集群中存储的版本兼容，防止存储版本漂移导致的数据不一致。
• 命名规范校验：强制资源名称符合正则表达式规则。

// Validating Webhook 拒绝响应示例
{
  "apiVersion": "admission.k8s.io/v1",
  "kind": "AdmissionReview",
  "response": {
    "uid": "705ab4f5-6393-11e8-b7cc-42010a800002",
    "allowed": false,
    "status": {
      "code": 403,
      "message": "Pod 使用 hostNetwork 被禁止，请移除 spec.hostNetwork: true"
    }
  }
}

3.4 两种 Webhook 的协同工作模式

在实际生产环境中，Mutating 和 Validating Webhook 经常配合使用，形成完整的准入控制链：

3.5 存储版本漂移场景下的选择建议