4. 控制平面准入控制概述：Admission Controller 概念、Mutating vs Validating Webhook、准入链工作流程
4.1 Admission Controller 核心概念
Admission Controller（准入控制器）是 Kubernetes API Server 请求处理链中的一个关键中间件组件。它位于请求被认证（Authentication）和授权（Authorization）之后、对象被持久化到 etcd 之前。准入控制器拦截发往 API Server 的请求，可以修改（Mutate）或验证（Validate）请求对象，从而实现对集群资源创建、更新、删除操作的精细化控制。
Kubernetes 内置了多种准入控制器插件（如 NamespaceLifecycle、LimitRanger、MutatingAdmissionWebhook、ValidatingAdmissionWebhook 等），管理员可以通过 --enable-admission-plugins 和 --disable-admission-plugins 参数控制其启用状态。
4.2 Mutating vs Validating Webhook 对比
Webhook 准入控制器允许集群管理员将自定义的准入逻辑注册为外部 HTTP 回调。根据执行阶段和功能差异，分为 MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook 两类。
| 对比维度 | MutatingAdmissionWebhook | ValidatingAdmissionWebhook |
|---|---|---|
| 执行顺序 | 先执行（在准入链中位于 Validating 之前） | 后执行（在 Mutating 之后） |
| 核心功能 | 修改（Mutate）请求对象，如注入 Sidecar、添加默认标签、修改资源规格 | 验证（Validate）请求对象，如检查配置合法性、强制安全策略、拒绝不合规请求 |
| 响应类型 | 返回 JSON Patch 操作（RFC 6902） |
返回 allowed: true/false 及拒绝消息 |
| 幂等性要求 | 必须幂等（同一对象多次修改结果一致） | 无强制幂等要求 |
| 典型场景 | ConfigMap 热更新时自动注入 Reloader Sidecar、设置默认资源配额 | 校验 ConfigMap 数据格式（如 YAML/JSON 合法性）、禁止挂载敏感路径 |
| 失败策略 | 支持 Fail 或 Ignore 模式 |
支持 Fail 或 Ignore 模式 |
4.3 准入链工作流程
Kubernetes API Server 处理一个资源请求时，会经过一个严格定义的准入链。下图展示了从客户端发起请求到对象持久化的完整流程：
完整的准入链处理步骤可归纳为以下流程：
- 客户端发起请求：用户或控制器通过 kubectl、REST API 或客户端库向 API Server 发送资源操作请求（如创建 Pod、更新 ConfigMap）。
- 认证（Authentication）：API Server 验证请求发起者的身份，支持 TLS 证书、Bearer 、HTTP Basic Auth 等多种方式。
- 授权（Authorization）：基于 RBAC、ABAC 或 Webhook 策略，判断请求主体是否拥有执行该操作的权限。
- 准入控制（Admission Control）：按顺序执行已启用的准入控制器插件，包括：
- MutatingAdmissionWebhook：调用外部 Webhook 服务修改请求对象（如注入 Sidecar、添加默认标签）。
- 对象模式变更：Kubernetes 内置的 Mutating 控制器（如
MutatingAdmissionWebhook插件）应用默认值。 - ValidatingAdmissionWebhook：调用外部 Webhook 服务验证请求对象（如检查 ConfigMap 数据格式）。
- 持久化到 etcd：所有准入控制器均通过后，请求对象被序列化并写入 etcd 存储。
allowed: false），整个请求将被立即终止，不会继续执行后续控制器，也不会持久化到 etcd。在 ConfigMap 热更新场景中，Webhook 服务的可用性和响应时间直接影响集群的请求处理延迟。
4.4 Webhook 配置与注册机制
管理员通过创建 MutatingWebhookConfiguration 和 ValidatingWebhookConfiguration 资源来注册外部 Webhook 服务。以下是一个典型的 Webhook 配置示例：
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
name: configmap-hotupdate-injector
webhooks:
- name: injector.example.com
clientConfig:
service:
name: webhook-service
namespace: kube-system
path: /mutate
caBundle: <base64-encoded-ca-cert>
rules:
- operations: ["CREATE", "UPDATE"]
apiGroups: [""]
apiVersions: ["v1"]
resources: ["pods"]
admissionReviewVersions: ["v1"]
sideEffects: None
timeoutSeconds: 10
reinvocationPolicy: IfNeeded
failurePolicy: Fail配置中的关键字段说明：
| 字段 | 说明 | ConfigMap 热更新场景建议 |
|---|---|---|
clientConfig |
指定外部 Webhook 服务的访问地址（Service 或 URL）及 TLS 证书 | 建议使用 Service 方式，部署在集群内，降低网络延迟 |
rules |
定义哪些资源操作需要触发 Webhook 调用 | 针对 Pod 的 CREATE/UPDATE 操作，确保热更新 Sidecar 注入 |
failurePolicy |
Webhook 调用失败时的处理策略：Fail 或 Ignore |
生产环境建议 Fail，避免绕过准入策略 |
timeoutSeconds |
Webhook 调用超时时间（1-30 秒） | 建议 5-10 秒，平衡可靠性与响应速度 |
reinvocationPolicy |
是否允许在后续 Mutating Webhook 执行后再次调用当前 Webhook | 热更新场景建议 IfNeeded，确保最终状态一致 |
4.5 准入控制与 ConfigMap 热更新的关联
在 ConfigMap 热更新场景中，准入控制机制承担以下关键职责：
- 自动注入热更新代理：通过 Mutating Webhook 在 Pod 创建时自动注入 Reloader 或类似 Sidecar 容器，监听 ConfigMap 变更并触发应用重载。
- 强制配置规范：通过 Validating Webhook 校验 ConfigMap 的键值对格式、命名规范、是否包含敏感信息等。
- 动态策略适配：结合 ConfigMap 热更新特性，准入控制器可以读取最新的策略配置（也存储在 ConfigMap 中），实现无需重启 Webhook 服务的策略热更新。
- 审计与合规：记录所有经过准入控制的资源变更，为审计和合规检查提供依据。