2. 准入控制概述：什么是准入控制、准入控制的工作流程、Mutating与Validating Webhook的区别
2.1 什么是准入控制
准入控制（Admission Control）是 Kubernetes API Server 在对象持久化到 etcd 之前执行的最后一道拦截层。它拦截所有对 API Server 的写请求（CREATE、UPDATE、DELETE），但不拦截只读请求（GET、LIST、WATCH）。
准入控制器本质上是一段插件代码，在请求经过认证（Authentication）和授权（Authorization）之后、对象被 etcd 存储之前运行。如果任何一个准入控制器拒绝请求，整个请求会被立即丢弃，错误信息返回给客户端。
核心作用： 准入控制是集群安全策略的“守门员”，用于强制执行命名空间配额、Pod 安全策略、资源限制、镜像签名验证等关键策略。
2.2 准入控制的工作流程
一个完整的 API 请求在 Kubernetes 中的处理流程如下：
- 认证（Authentication）： 验证请求发起者的身份（证书、、用户名/密码）。
- 授权（Authorization）： 判断请求者是否有权限执行该操作（RBAC、ABAC）。
- 准入控制（Admission Control）： 在对象被持久化前，按顺序执行所有配置的准入控制器插件。
- 持久化（Persist to etcd）： 通过所有准入检查后，对象被写入 etcd 存储。
准入控制阶段又细分为两个子阶段：
| 阶段 | 执行顺序 | 作用 |
|---|---|---|
| Mutating（变更） | 先执行 | 修改或补全请求对象（如注入 Sidecar、设置默认值） |
| Validating（验证） | 后执行 | 验证对象是否符合策略规则（如检查镜像来源、资源配额） |
设计原则： Mutating 阶段先于 Validating 阶段执行，确保 Validating 阶段看到的是经过所有变更后的最终对象，避免验证通过后又被修改导致策略绕过。
下图展示了 API 请求从客户端到 etcd 的完整准入控制流程：
2.3 Mutating 与 Validating Webhook 的区别
Kubernetes 提供了两种动态准入控制扩展机制：MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook。它们允许集群管理员通过外部 Webhook 服务自定义准入逻辑，而无需修改或重新编译 Kubernetes 核心组件。
| 对比维度 | Mutating Webhook | Validating Webhook |
|---|---|---|
| 执行阶段 | Mutating 阶段（先执行） | Validating 阶段（后执行） |
| 核心功能 | 修改/补全请求对象 | 验证/拒绝请求对象 |
| 典型场景 | 注入 Sidecar、设置默认资源限制、添加标签/注解 | 检查镜像签名、验证 Pod 安全策略、资源配额校验 |
| 返回结果 | 返回修改后的 JSON Patch | 返回 allowed（允许/拒绝） |
| 幂等性要求 | 必须幂等（多次调用结果一致） | 无特殊要求 |
| 失败策略 | 可配置 Fail 或 Ignore | 可配置 Fail 或 Ignore |
重要注意事项： Mutating Webhook 必须保证幂等性。如果同一个对象被多次调用 Mutating Webhook，每次返回的 JSON Patch 不能产生冲突或重复修改。否则可能导致 Admission 循环或对象状态不一致。
下图展示了 Mutating 和 Validating Webhook 在准入控制流程中的位置及交互关系：
2.4 实践建议
- 优先使用 Validating Webhook： 如果只需要做策略校验（如检查镜像是否来自可信仓库），优先使用 Validating Webhook，逻辑更简单，不易出错。
- Mutating Webhook 必须幂等： 由于同一个对象可能被多次调用 Mutating Webhook（如更新操作），必须确保每次修改结果一致，避免重复注入或冲突。
- 合理配置 failurePolicy： 对于关键策略（如安全策略），设置
failurePolicy: Fail；对于非关键策略（如默认值注入），设置failurePolicy: Ignore，避免 Webhook 服务故障影响集群可用性。 - 使用 timeoutSeconds 控制超时： 建议设置合理的超时时间（默认 10 秒），避免 Webhook 响应过慢拖慢整个 API 请求。
总结： 准入控制是 Kubernetes 安全体系的核心环节。理解 Mutating 和 Validating Webhook 的区别，能够帮助你在实际运维中正确设计策略执行顺序，避免因 Webhook 配置不当导致的集群故障或安全漏洞。