4. K8s准入控制原理：Admission Webhook、Mutating与Validating Webhook、OPA Gatekeeper架构
Kubernetes 准入控制（Admission Control）是 API 请求处理链中最后一道内置防线，位于认证、授权之后，对象持久化之前。理解这一机制是掌握 OPA Gatekeeper 工作原理的基础。本章将深入剖析准入控制链、两种 Webhook 的差异，以及 Gatekeeper 如何利用它们实现策略即代码。
4.1 准入控制链与 Webhook 位置
一个 Kubernetes API 请求从客户端发出到最终写入 etcd，会依次经过以下阶段：
- 认证（Authentication）：验证请求者身份（TLS 证书、、Basic Auth）。
- 授权（Authorization）：判断请求者是否有权限执行操作（RBAC、ABAC）。
- 准入控制（Admission Control）：拦截请求，执行变更或校验逻辑。
- 持久化（Persistence）：将对象写入 etcd。
关键认知： 准入控制器是唯一能修改或拒绝 API 请求的插件层。认证和授权只能决定“能不能做”，而准入控制决定“怎么做”以及“是否允许做”。
Kubernetes 内置了多种准入控制器（如 NamespaceLifecycle、LimitRanger、ResourceQuota），但更灵活的方式是通过 动态准入 Webhook 调用外部服务。
4.2 Mutating 与 Validating Webhook 对比
动态准入 Webhook 分为两种类型，它们在执行顺序、职责和风险上存在本质区别：
| 特性 | MutatingAdmissionWebhook | ValidatingAdmissionWebhook |
|---|---|---|
| 执行顺序 | 先执行（在链中靠前） | 后执行（在链中靠后） |
| 核心能力 | 修改（Patch）请求对象 | 只读校验，不修改对象 |
| 典型场景 | 注入 Sidecar、设置资源默认值、添加标签/注解 | 检查镜像签名、验证 Pod 安全上下文、合规性审计 |
| 幂等性要求 | 必须幂等（同一对象多次修改结果一致） | 必须幂等（同一对象多次校验结果一致） |
| 失败策略 | 可配置 failurePolicy: Fail/Ignore |
可配置 failurePolicy: Fail/Ignore |
| 超时控制 | 默认 30 秒，建议 ≤ 5 秒 | 默认 30 秒，建议 ≤ 5 秒 |
| 风险 | 修改不当可能导致对象状态不一致 | 误拒绝可能导致服务中断 |
性能陷阱： Webhook 超时是 K8s API 延迟的常见来源。如果 Webhook 服务响应超过 30 秒（或自定义超时），API Server 会记录超时错误，并可能根据 failurePolicy 忽略或拒绝请求。建议将 Webhook 响应时间控制在 100ms 以内，并设置合理的超时值（如 3-5 秒）。
4.3 OPA Gatekeeper 架构深度解析
OPA Gatekeeper 是 CNCF 毕业项目，它将 OPA 策略引擎与 K8s 准入 Webhook 深度集成。其核心架构包含三个组件：
- Gatekeeper Controller Manager：管理 CRD（ConstraintTemplate、Constraint）的生命周期，将 Rego 策略编译为 OPA 可执行格式。
- Gatekeeper Webhook Server：注册为 Mutating 和 Validating Webhook，接收 K8s API Server 的 AdmissionReview 请求，调用 OPA 引擎执行策略评估。
- OPA Engine（内置）：运行 Rego 策略，输出决策结果（allow/deny + 消息）。
Gatekeeper 的工作流程如下：
- 管理员创建
ConstraintTemplate，定义 Rego 策略模板。 - 管理员创建
Constraint（CRD 实例），指定策略参数（如允许的镜像仓库列表）。 - 用户提交 Pod/Deployment 等资源到 K8s API Server。
- API Server 将请求发送到 Gatekeeper Webhook（Mutating 或 Validating）。
- Gatekeeper 将请求对象转换为 OPA 输入（input），执行 Rego 策略。
- OPA 返回决策：
{"allowed": true/false, "message": "..."}。 - Gatekeeper 将决策封装为 AdmissionResponse，返回给 API Server。
- 如果 allowed: false，API Server 拒绝请求并返回错误给用户。
4.4 Gatekeeper 核心 CRD 与策略生命周期
Gatekeeper 通过两个关键 CRD 实现策略的声明式管理：
| CRD 名称 | 作用 | 示例内容 |
|---|---|---|
ConstraintTemplate |
定义 Rego 策略模板，包含参数 schema 和 Rego 代码 | 检查所有 Pod 必须设置 resources.limits.cpu |
Constraint |
实例化模板，传入具体参数（如允许的命名空间列表） | 在 production 命名空间强制 CPU limit 为 4 核 |
策略生命周期管理流程：
- 定义：编写 Rego 策略，封装为
ConstraintTemplate。 - 安装：
kubectl apply -f constraint-template.yaml，Gatekeeper 控制器编译并注册策略。 - 实例化：创建
Constraint对象，指定生效范围（如match: namespaces: ["production"]）。 - 生效：Gatekeeper Webhook 自动拦截匹配的请求，执行策略评估。
- 更新：修改 Constraint 或 ConstraintTemplate，Gatekeeper 自动热加载。
- 删除：删除 Constraint 停止策略执行；删除 ConstraintTemplate 需先删除所有关联 Constraint。
最佳实践： 将 ConstraintTemplate 视为“策略代码”，纳入 GitOps 管理；将 Constraint 视为“策略配置”，按环境（dev/staging/prod）差异化部署。这样既能复用策略逻辑，又能灵活控制生效范围。
4.5 性能考量：Webhook 对 API 延迟的影响
Webhook 是 K8s API 延迟的敏感点。Gatekeeper 作为 Webhook 服务，其性能直接影响集群响应速度：
- 评估耗时：Rego 策略复杂度决定 OPA 评估时间。简单策略（如标签检查）通常 < 1ms；复杂策略（如跨资源遍历）可能达到 10-50ms。
- 网络延迟：API Server 与 Gatekeeper 之间的网络往返（通常 < 1ms 同集群内）。
- 序列化/反序列化：AdmissionReview 对象的 JSON 编解码开销，大对象（如包含大量数据的 ConfigMap）可能增加 5-20ms。
- 并发处理：Gatekeeper 默认使用 10 个工作协程，高并发场景下可能排队。