Kubernetes 准入控制基础：Admission Controller 概念、Mutating 与 Validating Webhook、准入控制链

1. 什么是 Admission Controller？

Admission Controller（准入控制器）是 Kubernetes API Server 请求处理链中的一个关键组件，位于请求认证（Authentication）和授权（Authorization）之后，对象持久化（etcd 存储）之前。它拦截所有对 API Server 的请求，并根据预定义的逻辑对请求进行修改、验证或拒绝。

核心定位：准入控制器是 Kubernetes 集群的“策略执行网关”，确保所有资源操作符合集群的安全规范、资源配额和自定义策略。

Kubernetes 内置了 30+ 个准入控制器，例如 NamespaceLifecycle、LimitRanger、ResourceQuota、PodSecurity 等。管理员可以通过 API Server 的 --enable-admission-plugins 和 --disable-admission-plugins 参数控制启用哪些控制器。

2. 准入控制链：请求处理流程

一个 Kubernetes API 请求从客户端发出到最终持久化，需要经过以下完整链路：

  1. 认证（Authentication）：验证请求发起者的身份（TLS 证书、、用户名/密码）。
  2. 授权（Authorization）：检查请求者是否有权限执行该操作（RBAC、ABAC、Node 授权）。
  3. 准入控制（Admission Control）：按顺序执行所有启用的准入控制器，包括 Mutating 和 Validating 阶段。
  4. 对象持久化（etcd）：通过准入检查后，资源对象被写入 etcd 存储。
Kubernetes API 请求处理链路 客户端 认证 授权 准入控制 Mutating → Validating etcd 存储 拒绝（Reject） 说明： 准入控制是唯一可以修改请求内容（Mutating）和基于集群状态做决策（Validating）的阶段。 认证和授权阶段只能判断“你是谁”和“你能做什么”，不能修改请求体或感知集群当前状态。

3. Mutating 与 Validating Webhook

Kubernetes 提供了两种动态准入控制机制，允许集群管理员通过 Webhook 扩展准入控制逻辑，而无需修改或重新编译 API Server：

特性 MutatingAdmissionWebhook ValidatingAdmissionWebhook
执行顺序 先执行（在准入控制链的 Mutating 阶段） 后执行（在准入控制链的 Validating 阶段）
核心功能 修改（Patch）请求中的资源对象 验证请求中的资源对象，拒绝不合规请求
典型场景 注入 Sidecar、设置默认值、添加标签/注解 校验资源命名规范、检查镜像来源、强制执行安全策略
返回结果 返回 JSON Patch 或允许通过 返回允许（Allowed: true）或拒绝（Allowed: false + 原因）
幂等性要求 必须幂等（多次执行结果一致） 无特殊要求
重要顺序规则：所有 Mutating Webhook 执行完毕后，API Server 会对修改后的对象重新执行一次 Validating Webhook。这意味着 Validating Webhook 看到的是经过所有 Mutating Webhook 修改后的最终对象版本。

4. Webhook 配置核心要素

配置一个 Webhook 准入控制器需要两个关键资源：

  • ValidatingWebhookConfiguration / MutatingWebhookConfiguration：定义 Webhook 的触发规则、服务地址、超时时间、失败策略等。
  • Webhook 服务：运行在集群内的 HTTPS 服务，处理准入审查请求并返回 AdmissionReview 响应。

以下是一个 MutatingWebhookConfiguration 的配置示例：

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: kube-system
      path: /mutate
    caBundle: <base64-encoded-ca-cert>
  rules:
  - operations: ["CREATE"]
    apiGroups: [""]
    apiVersions: ["v1"]
    resources: ["pods"]
  failurePolicy: Fail
  sideEffects: None
  admissionReviewVersions: ["v1"]
  timeoutSeconds: 10
  reinvocationPolicy: IfNeeded
  objectSelector:
    matchLabels:
      sidecar-injector: enabled
关键参数说明：
failurePolicy：当 Webhook 服务不可达时，设置为 Fail 会拒绝请求，Ignore 则允许请求继续。
reinvocationPolicy：如果后续有其他 Mutating Webhook 修改了对象，是否重新调用此 Webhook。
objectSelector：通过标签选择器精确控制哪些资源触发 Webhook，减少不必要的调用。

5. 准入控制链的完整执行顺序

当多个准入控制器和 Webhook 同时启用时，执行顺序遵循以下规则：

  1. 内置 Mutating 控制器（如 NamespaceLifecycle、MutatingAdmissionPolicy）
  2. MutatingWebhookConfiguration（按名称字母顺序执行）
  3. 内置 Validating 控制器（如 PodSecurity、ResourceQuota）
  4. ValidatingWebhookConfiguration（按名称字母顺序执行）
准入控制链详细执行顺序 内置 Mutating 控制器 NamespaceLifecycle 等 Mutating Webhook 按名称字母顺序 内置 Validating 控制器 PodSecurity, ResourceQuota Validating Webhook 按名称字母顺序 任一阶段拒绝 → 请求终止，不进入下一阶段 注意：Mutating Webhook 修改对象后，API Server 会重新执行 Validating 阶段，确保最终对象符合所有验证规则。 如果多个 Mutating Webhook 修改同一字段，后执行的 Webhook 会覆盖先执行的修改。

6. 多集群场景下的准入控制挑战

在管理多个 Kubernetes 集群时，准入控制面临以下特殊挑战：

挑战 描述 推荐方案
配置一致性 确保所有集群的准入控制策略保持一致 使用 GitOps 管理 Webhook 配置，通过 CI/CD 同步到所有集群
证书管理 每个 Webhook 服务需要 TLS 证书，多集群下证书分发复杂 使用 cert-manager 自动签发和轮换证书
故障隔离 一个集群的 Webhook 故障不应影响其他集群 每个集群独立部署 Webhook 服务，设置合理的 failurePolicy
策略差异化 不同集群可能需要不同的准入规则（如生产/测试环境） 使用标签或命名空间选择器区分集群环境
最佳实践：在多集群环境中，建议将 Webhook 配置与集群配置一起版本化管理。使用 kustomize 或 helm 模板化 Webhook 配置，通过参数化区分不同集群的差异化策略。
← 上一章 📖 返回目录 下一章 →