基于准入控制的策略即代码资源配额模型架构设计 - 第2节
Kubernetes 准入控制基础：Admission Controller 工作原理
Kubernetes 准入控制（Admission Control）是 API Server 请求链中一道关键的“门禁”。任何对集群资源进行创建、更新、删除的请求，在完成身份认证（Authentication）和授权（Authorization）之后、资源被持久化到 etcd 之前，都必须依次通过准入控制器的检查。如果任一控制器拒绝，请求将被立即终止，不会写入 etcd。
准入控制请求处理流程
一个完整的 API 请求在 Kubernetes 内部经过以下阶段：
- 认证（Authentication）：验证请求发起者的身份（证书、、用户名/密码）。
- 授权（Authorization）：判断该身份是否拥有执行操作的权限（RBAC、ABAC）。
- 准入控制（Admission Control）：对请求内容进行语义检查、默认值注入、策略校验。
- 持久化（etcd）：通过所有准入检查后，资源对象被写入后端存储。
关键理解： 准入控制器是唯一能够拦截并修改请求内容（Mutating）或拒绝请求（Validating）的组件，且运行在 API Server 进程内，具有极高的执行优先级。
Mutating vs Validating Webhook
Kubernetes 内置了数十种编译进 API Server 的准入控制器（如 NamespaceLifecycle、ResourceQuota、PodSecurity），但更灵活的方式是通过 Dynamic Admission Control 动态注册外部 Webhook。Webhook 分为两类：MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook。
MutatingAdmissionWebhook（变更型）
- 执行时机：在 Validating Webhook 之前运行。
- 核心职责：修改（Patch）请求中的资源对象，例如注入 Sidecar、设置默认资源限制、添加标签/注解。
- 幂等性要求：同一个对象可能被多次修改，Webhook 必须保证幂等，避免重复注入。
- 典型场景：Istio Sidecar 注入、Kyverno 默认值策略、自定义调度器标签。
ValidatingAdmissionWebhook（校验型）
- 执行时机：在 Mutating Webhook 之后运行。
- 核心职责：校验请求中的资源对象是否符合集群策略，拒绝不合规的请求。
- 只读原则：不允许修改请求内容，只能返回允许（Allowed）或拒绝（Denied）。
- 典型场景：禁止特权容器、强制资源配额、检查镜像来源。
最佳实践： 将“默认值注入”放在 Mutating Webhook 中，将“策略校验”放在 Validating Webhook 中。这样 Validating 看到的是经过完整补全后的对象，校验逻辑更简洁、更准确。
Mutating vs Validating 核心对比
| 对比维度 | MutatingAdmissionWebhook | ValidatingAdmissionWebhook |
|---|---|---|
| 执行顺序 | 先执行 | 后执行 |
| 是否可修改对象 | 是（通过 JSON Patch） | 否（只读） |
| 返回结果 | 允许 + 修改后的对象 | 允许 / 拒绝 + 错误消息 |
| 幂等性 | 必须保证幂等 | 无需考虑幂等 |
| 失败策略 | Fail / Ignore | Fail / Ignore |
| 超时控制 | 30 秒（可配置） | 30 秒（可配置） |
Webhook 配置示例（YAML）
以下是一个典型的 ValidatingAdmissionWebhook 配置，用于校验 Pod 是否包含特定标签：
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionWebhookConfiguration
metadata:
name: "pod-label-validator.example.com"
webhooks:
- name: "pod-label-validator.example.com"
clientConfig:
service:
namespace: "webhook-system"
name: "webhook-service"
path: "/validate"
caBundle: "LS0tLS1CRUdJTiBDRV...=="
rules:
- operations: ["CREATE", "UPDATE"]
apiGroups: [""]
apiVersions: ["v1"]
resources: ["pods"]
failurePolicy: Fail
sideEffects: None
admissionReviewVersions: ["v1"]
注意： 生产环境中务必为 Webhook 配置
failurePolicy: Fail 或 Ignore，并设置合理的 timeoutSeconds（默认 30 秒）。如果 Webhook 服务不可用且 failurePolicy: Fail，整个集群的写入操作将被阻塞。
Webhook 的幂等性与副作用控制
- 幂等性：Mutating Webhook 必须确保多次调用同一请求产生相同结果。例如注入 Sidecar 时，应检查容器是否已存在，避免重复注入。
- sideEffects：Webhook 配置中需声明
sideEffects: None（无副作用）或sideEffects: NoneOnDryRun，告知 API Server 该 Webhook 在 dry-run 模式下是否安全。 - reinvocationPolicy：Mutating Webhook 可设置
reinvocationPolicy: IfNeeded，允许在后续 Webhook 修改对象后再次调用当前 Webhook，确保最终状态正确。
总结
准入控制是 Kubernetes 策略即代码的基石。Mutating Webhook 负责“修正”请求，Validating Webhook 负责“把关”合规。两者配合使用，可以构建出强大且灵活的集群治理体系，为后续实现资源配额模型提供核心执行引擎。