4. OPA Gatekeeper 架构：核心组件与工作流程
OPA Gatekeeper 是 Kubernetes 原生的策略引擎，它将 OPA 的策略即代码能力以 Admission Webhook 的形式集成到集群控制平面中。理解 Gatekeeper 的架构，关键在于掌握其三大核心组件——Admission Controller、ConstraintTemplate 和 Constraint——以及它们之间的协作流程。
4.1 三大核心组件
| 组件 | 角色 | 关键特征 |
|---|---|---|
| Admission Controller | 策略执行入口 | 作为 Kubernetes API Server 的 Webhook，拦截资源变更请求，调用 OPA 引擎进行策略评估，并返回允许/拒绝决策。 |
| ConstraintTemplate | 策略模板定义 | 使用 Rego 语言编写策略逻辑，定义参数 schema（parameters）和具体规则（violation）。是策略的“类”或“蓝图”。 |
| Constraint | 策略实例化 | 通过 CRD（Custom Resource Definition）实例化 ConstraintTemplate，传入具体参数（如配额上限、允许的命名空间标签等），形成可执行的策略规则。 |
类比理解： ConstraintTemplate 相当于编程语言中的“类”，Constraint 则是“对象”。Template 定义逻辑结构，Constraint 提供具体配置并生效。
4.2 组件工作流程
当用户通过 kubectl apply 创建或更新资源时，Gatekeeper 的完整工作流程如下：
- 请求拦截： Kubernetes API Server 将资源变更请求发送至 Gatekeeper 的 Admission Webhook。
- 策略匹配： Gatekeeper 根据请求的资源类型（如 Pod、Namespace）和操作（CREATE/UPDATE），匹配已安装的 Constraint。
- Rego 评估： 匹配到的 Constraint 引用其对应的 ConstraintTemplate，将请求的 AdmissionReview 对象作为输入，执行 Rego 策略逻辑。
- 决策返回： OPA 引擎返回评估结果（allow/deny）及可选的审计消息。Gatekeeper 将结果封装为 AdmissionResponse，返回给 API Server。
- 最终执行： API Server 根据返回的决策，允许资源写入 etcd 或拒绝请求并返回错误信息给用户。
关键点： 整个评估过程是同步的，发生在资源持久化之前。这意味着 Gatekeeper 可以防止违反策略的资源被创建，实现“预防性”合规控制。
4.3 架构交互关系
下图展示了 Gatekeeper 组件之间的静态依赖关系以及运行时数据流：
4.4 组件部署与生命周期
Gatekeeper 组件以 Kubernetes 原生资源的形式存在，其生命周期管理遵循以下模式：
- Admission Controller：以 Deployment 形式运行在
gatekeeper-system命名空间中，通过 Service 暴露 Webhook 端点。 - ConstraintTemplate：作为集群级别的 CRD 安装。创建后，Gatekeeper 控制器会自动生成对应的 CRD 类型。
- Constraint：作为自定义资源实例（CR）创建，引用已存在的 ConstraintTemplate。创建后立即生效，无需重启任何组件。
注意： 删除 ConstraintTemplate 前，必须先删除所有引用它的 Constraint，否则会导致残留 CRD 和孤儿资源，引发控制器错误。
4.5 审计模式与准入模式
Gatekeeper 支持两种运行模式，在资源配额模型配置漂移审计中均发挥重要作用：
| 模式 | 触发时机 | 用途 | 对漂移审计的价值 |
|---|---|---|---|
| 准入模式（Admission） | 资源创建/更新时 | 实时拦截违规请求 | 预防配额配置被直接修改 |
| 审计模式（Audit） | 定时扫描（默认每 60 秒） | 检测已存在的违规资源 | 发现绕过准入或历史遗留的漂移 |
审计模式通过 Constraint 的 status 字段报告违规结果，运维人员可通过 kubectl get constraint 查看审计状态，这是检测配置漂移的重要数据源。