📚 课程目录第2章 Kubernetes Admission Controller 基础

2. Kubernetes Admission Controller 基础

Admission Controller（准入控制器）是 Kubernetes API Server 请求链路上的关键拦截层，负责在对象被持久化到 etcd 之前执行校验、修改或拒绝逻辑。对于策略即代码（Policy as Code）场景，Admission Controller 是资源配额模型与发布包完整性校验的核心执行引擎。

2.1 Admission Controller 工作原理

Kubernetes API Server 处理一个资源请求（如创建 Pod）时，请求会依次经过：认证（Authentication）→ 授权（Authorization）→ 准入控制（Admission Control）→ 持久化到 etcd。Admission Controller 位于授权之后、持久化之前，分为两个阶段：Mutating（变更）和 Validating（校验）。

实践要点：在策略即代码场景中，Mutating Webhook 常用于注入资源配额标签或默认限制，Validating Webhook 用于校验发布包完整性（如镜像摘要、Helm Chart 签名）。两者配合可实现“先修复、后校验”的自动化策略。

2.2 Mutating vs Validating Webhook

Admission Webhook 是 Kubernetes 内置的两种动态准入控制器，允许集群管理员通过外部 HTTP 回调扩展准入逻辑。下表对比两者的核心差异：

对比维度	Mutating Webhook	Validating Webhook
执行顺序	先执行（在 Mutating 阶段）	后执行（在 Validating 阶段）
核心能力	修改（Patch）请求对象	校验（Validate）请求对象
典型用途	注入 Sidecar、设置默认资源限制、添加标签/注解	校验资源配额、检查镜像签名、验证 Pod 安全策略
返回类型	返回 JSON Patch 或 JSON Merge Patch	返回 allowed（true/false）及拒绝消息
幂等性要求	必须幂等（多次调用结果一致）	无强制要求，但建议幂等
失败策略	支持 Fail / Ignore	支持 Fail / Ignore

  策略即代码场景建议：资源配额模型推荐使用 Validating Webhook 进行硬性校验，确保每个工作负载不超过定义的配额上限；发布包完整性校验（如 Cosign 签名验证）也使用 Validating Webhook。Mutating Webhook 可用于自动注入配额标签或默认资源限制，减少人工配置遗漏。

2.3 Webhook 配置与生命周期

Webhook 的配置通过 Kubernetes 原生资源 MutatingWebhookConfiguration 和 ValidatingWebhookConfiguration 完成。以下是一个 ValidatingWebhookConfiguration 的示例：

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: "resource-quota-validator.example.com"
webhooks:
- name: "resource-quota-validator.example.com"
  clientConfig:
    service:
      name: quota-validator-svc
      namespace: admission-system
      path: "/validate"
    caBundle: "LS0tLS1CRUdJTiBDRV...=="
  rules:
  - operations: ["CREATE", "UPDATE"]
    apiGroups: [""]
    apiVersions: ["v1"]
    resources: ["pods"]
  failurePolicy: Fail
  matchPolicy: Equivalent
  sideEffects: None
  timeoutSeconds: 10
  admissionReviewVersions: ["v1"]
  objectSelector:
    matchLabels:
      quota-controlled: "true"

Webhook 的生命周期包含以下关键阶段：

配置阶段：管理员创建 MutatingWebhookConfiguration 或 ValidatingWebhookConfiguration 资源，指定 Webhook 服务地址、规则、证书等。
注册阶段：Kubernetes API Server 加载配置，将 Webhook 注册到准入链中。
调用阶段：当请求匹配 rules 时，API Server 发送 AdmissionReview 请求到 Webhook 服务，等待响应。
超时与重试：默认超时 10 秒（可配置），超时后根据 failurePolicy 决定拒绝（Fail）或忽略（Ignore）请求。
更新与删除：更新 Webhook 配置后，API Server 动态加载新配置；删除配置后，Webhook 从准入链中移除。

常见陷阱：

循环调用：Webhook 服务本身不能触发自身匹配的规则，否则会导致死循环。
证书过期：Webhook 使用 TLS 通信，caBundle 中的 CA 证书过期会导致调用失败。
sideEffects 声明：必须正确声明 sideEffects: None 或 NoneOnDryRun，否则 dry-run 请求可能被拒绝。
objectSelector 误用：不当的标签选择器可能导致 Webhook 漏掉本应校验的资源。

2.4 Webhook 调用时序与策略即代码集成

在策略即代码架构中，Webhook 的调用时序直接影响资源配额模型和发布包完整性的校验效果。下图展示了集成后的完整调用链路：

生产建议：将 Mutating Webhook 和 Validating Webhook 部署在独立的命名空间（如 admission-system），并配置 failurePolicy: Fail 确保关键策略不被绕过。同时，为 Webhook 服务配置 horizontalPodAutoscaler 以应对高并发场景。