3. Kubernetes 准入控制：Admission Webhook 原理、ValidatingAdmissionPolicy 与 OPA 集成、Kube-mgmt 与 Gatekeeper 对比

在 Multi-Cluster 变更门禁体系中，Kubernetes 准入控制是策略执行的“最后一公里”。本章深入剖析 Admission Webhook 的核心原理，对比原生 ValidatingAdmissionPolicy 与 OPA 的集成方案，并重点分析 Kube-mgmt 与 Gatekeeper 在架构、运维与策略管理上的关键差异。

3.1 Admission Webhook 原理与请求生命周期

Kubernetes 准入控制分为两个阶段：Mutating（变更）和 Validating（验证）。Webhook 通过 HTTP 回调机制，允许外部策略引擎在资源持久化前介入决策。

3.2 ValidatingAdmissionPolicy 与 OPA 集成

Kubernetes 1.26+ 提供了原生的 ValidatingAdmissionPolicy（VAP），使用 Common Expression Language（CEL）编写策略，无需部署外部 Webhook 服务。OPA 则通过 Admission Webhook 模式集成，使用 Rego 语言编写策略。

3.3 Kube-mgmt 与 Gatekeeper 对比

Kube-mgmt 和 Gatekeeper 都是 OPA 在 Kubernetes 上的集成方案，但架构设计和运维模式差异显著。

3.3.1 Kube-mgmt：轻量级 Sidecar 模式

Kube-mgmt 作为 OPA 的 Sidecar 容器运行，负责将 Kubernetes 资源（如 ConfigMap、Namespace）同步到 OPA 的 data 缓存中，使 Rego 策略可以查询集群状态。

• 架构特点： OPA + Kube-mgmt Sidecar，每个节点或每个命名空间独立部署。
• 策略分发： 通过 ConfigMap 挂载 Rego 文件，Kube-mgmt 自动监听并更新。
• 运维复杂度： 较低，适合小规模集群或 PoC 场景。
• 局限性： 缺乏审计、约束模板、集群级策略管理等高级功能。

3.3.2 Gatekeeper：企业级策略引擎

Gatekeeper 是 CNCF 毕业项目，基于 OPA 构建，提供完整的策略管理框架，包括 ConstraintTemplate、Constraint 和 Audit 机制。

• 架构特点： 独立的 Admission Webhook 服务，支持集群级策略管理。
• 策略模型： 使用 ConstraintTemplate 定义 Rego 模板，Constraint 实例化具体规则。
• 审计功能： 内置审计引擎，可定期检查现有资源是否符合策略。
• Multi-Cluster 支持： 可通过 GitOps 或策略分发工具统一管理。

3.4 迁移场景下的选型建议

在 Multi-Cluster 变更门禁策略迁移中，推荐以下决策路径：

1. 从 Kube-mgmt 迁移到 Gatekeeper： 如果当前使用 Kube-mgmt 且需要审计、约束模板、集群级策略管理，迁移到 Gatekeeper 是自然演进。
2. 从原生 VAP 迁移到 OPA： 当策略复杂度超出 CEL 能力（如需要外部数据查询、复杂循环逻辑），或需要统一策略语言时，选择 OPA + Gatekeeper。
3. 混合使用： 简单策略使用 VAP，复杂策略使用 Gatekeeper，通过 Webhook 优先级控制执行顺序。