3. K8s Webhook 概述：Admission Webhook（Mutating & Validating）、Webhook 在 K8s 中的角色

Kubernetes 的 API 请求处理链路中，准入控制（Admission Control） 是资源持久化到 etcd 之前的最后一道防线。Admission Webhook 将这一环节从内置插件扩展为外部 HTTP 回调，使得平台团队可以在资源创建、更新、删除时注入自定义的校验与修改逻辑，是 K8s 平台化落地的核心扩展机制。

3.1 什么是 Admission Webhook

Admission Webhook 是一种 动态准入控制 机制。它允许集群管理员注册外部 HTTP 服务，当特定 API 请求到达 API Server 时，API Server 会向该服务发送 AdmissionReview 请求，并根据返回结果决定是否允许请求继续执行。

根据处理阶段的不同，Admission Webhook 分为两类：

3.2 Webhook 在 K8s 中的角色定位

在 Kubernetes 的整体架构中，Webhook 扮演着 策略执行网关 和 资源增强器 的双重角色。它位于 API Server 内部处理流程的关键节点上，与认证、授权、内置准入控制器共同构成完整的请求处理链。

3.3 Webhook 的核心工作流程

当客户端（kubectl、控制器、API 调用）向 API Server 发送资源请求时，Webhook 的介入遵循以下步骤：

1. 请求到达 API Server：经过认证（Authentication）和授权（Authorization）后，进入准入控制阶段。
2. 匹配 Webhook 规则：API Server 根据注册的 MutatingWebhookConfiguration 或 ValidatingWebhookConfiguration 中的 rules 字段，判断当前请求是否匹配该 Webhook 的生效范围（API 组、资源、操作类型）。
3. 构造 AdmissionReview 请求：API Server 将请求中的资源对象封装为 AdmissionReview 对象，通过 HTTPS 发送给 Webhook 服务。
4. Webhook 服务处理：外部服务解析 AdmissionReview，执行自定义逻辑（修改或校验），返回包含 allowed 和 patch 的 AdmissionReview 响应。
5. API Server 执行决策：若 Webhook 返回 allowed: false，请求被拒绝；若为 Mutating Webhook，API Server 应用返回的 JSON Patch 修改对象。
6. 继续后续处理：所有 Webhook 执行完毕后，进入内置准入控制器，最终将对象持久化到 etcd。

3.4 Mutating 与 Validating 的协作模式

在实际平台落地中，Mutating 和 Validating Webhook 通常成对出现，形成 先修改、后校验 的协作模式。以下表格对比了二者的协作关系：

3.5 Webhook 配置的核心字段

注册一个 Webhook 需要创建对应的配置资源。以下是 MutatingWebhookConfiguration 和 ValidatingWebhookConfiguration 的核心字段说明：

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
  name: "example-mutating-webhook"
webhooks:
- name: "sidecar-injector.example.com"
  clientConfig:
    service:
      name: webhook-service
      namespace: webhook-system
      path: "/mutate"
    caBundle: "LS0tLS1CRUdJTiBDRV...=="
  rules:
  - operations: ["CREATE"]
    apiGroups: [""]
    apiVersions: ["v1"]
    resources: ["pods"]
  admissionReviewVersions: ["v1"]
  sideEffects: None
  timeoutSeconds: 10
  reinvocationPolicy: IfNeeded
  failurePolicy: Fail

3.6 Webhook 在平台落地中的典型角色

在 K8s 平台化实践中，Webhook 承担着以下关键角色：

• 策略执行者：强制实施命名规范、标签标准、资源配额限制、安全上下文约束等平台级策略。
• 自动化注入器：自动为 Pod 注入 Sidecar 代理（如 Istio Envoy）、日志采集器（如 Fluent Bit）、监控指标暴露器。
• 默认值提供者：为未显式设置的字段填充合理的默认值，降低用户使用复杂度。
• 资源校验网关：在资源进入集群前拦截不合规的配置，避免错误配置导致集群不稳定。
• 多租户隔离器：根据命名空间或标签，为不同租户的资源注入不同的配置或执行不同的校验规则。