3. Admission Webhook 分类：MutatingAdmissionWebhook 与 ValidatingAdmissionWebhook 的区别与适用场景

在 Kubernetes 准入控制链中，Admission Webhook 是动态扩展准入逻辑的核心机制。根据对请求资源的修改权限，官方将其明确划分为两类：MutatingAdmissionWebhook（变更型）与 ValidatingAdmissionWebhook（验证型）。理解两者的本质区别与适用场景，是正确设计 Webhook 控制器的基础。

3.1 核心区别：变更 vs. 验证

两类 Webhook 在 API 请求处理流程中的位置不同，职责边界清晰：

3.2 执行流程与顺序

下图展示了两类 Webhook 在 Kubernetes API 请求准入阶段中的完整执行顺序：

3.3 适用场景对比

根据两类 Webhook 的特性，以下列出典型适用场景：

MutatingAdmissionWebhook 适用场景

• Sidecar 自动注入：如 Istio/Linkerd 的 Envoy 代理注入，在 Pod 创建时自动添加 initContainer 和 sidecar 容器。
• 默认值填充：为未指定字段设置合理的默认值，例如资源限制（resources.limits）、调度策略（nodeSelector）。
• 标签/注解注入：自动添加审计标签、成本分摊标签、环境标识注解。
• 存储类默认设置：为未指定 storageClassName 的 PVC 注入默认存储类。
• 安全上下文加固：自动设置 runAsNonRoot、readOnlyRootFilesystem 等安全策略。

ValidatingAdmissionWebhook 适用场景

• 合规策略检查：禁止使用特权容器、禁止挂载宿主机敏感路径、禁止使用 latest 镜像标签。
• 资源配额校验：确保 Deployment 副本数不超过集群上限，确保容器请求/限制比例合理。
• 命名空间隔离规则：禁止跨命名空间引用 Secret/ConfigMap，禁止非授权命名空间创建特定资源。
• 自定义业务规则：如数据库实例名称必须符合命名规范、Ingress 域名必须属于已备案域名列表。
• 变更审计与告警：记录所有违反策略的请求，但不一定拒绝（可通过 allowed: true 配合审计日志实现）。

3.4 配置示例对比

以下展示两类 Webhook 在 YAML 配置中的关键差异：

# MutatingAdmissionWebhook 示例（sidecar 注入）
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
  name: sidecar-injector.example.com
webhooks:
- name: sidecar-injector.example.com
  clientConfig:
    service:
      name: sidecar-injector
      namespace: istio-system
      path: /inject
    caBundle: <base64-ca-cert>
  rules:
  - operations: ["CREATE"]
    apiGroups: [""]
    apiVersions: ["v1"]
    resources: ["pods"]
  admissionReviewVersions: ["v1"]
  sideEffects: None
  timeoutSeconds: 10
  reinvocationPolicy: IfNeeded  # 支持重新调用
---
# ValidatingAdmissionWebhook 示例（策略检查）
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: policy-checker.example.com
webhooks:
- name: policy-checker.example.com
  clientConfig:
    service:
      name: policy-checker
      namespace: policy-system
      path: /validate
    caBundle: <base64-ca-cert>
  rules:
  - operations: ["CREATE", "UPDATE"]
    apiGroups: ["apps"]
    apiVersions: ["v1"]
    resources: ["deployments"]
  admissionReviewVersions: ["v1"]
  sideEffects: None
  timeoutSeconds: 5
  failurePolicy: Fail  # 校验失败时拒绝请求

3.5 选择决策树

在实际开发中，可通过以下决策树快速判断应使用哪类 Webhook：

3.6 混合使用的最佳实践

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

1. 先注入默认值：使用 Mutating Webhook 为资源填充缺失字段（如资源限制、标签、sidecar）。
2. 再校验最终状态：使用 Validating Webhook 检查经过注入后的完整对象是否符合策略。
3. 避免重复校验：Validating Webhook 不应重复检查 Mutating Webhook 已经保证的字段（如默认值是否存在），而应关注业务语义层面的合规性。
4. 日志与监控：两类 Webhook 都应输出结构化日志，记录 admissionReview 的 UID、操作类型、资源标识以及决策结果，便于调试和审计。