3. Gatekeeper 组件架构：Admission Controller、Constraint Framework、Constraint Template

OPA Gatekeeper 的核心架构围绕三个关键组件构建：Admission Controller（准入控制器）、Constraint Framework（约束框架）和 Constraint Template（约束模板）。三者协同工作，将策略定义、策略实例化与策略执行解耦，形成可扩展、可复用的策略引擎体系。

3.1 组件总览与职责划分

下表清晰展示了三个核心组件在 Gatekeeper 架构中的角色与职责：

3.2 组件交互流程与架构图

下图展示了 Gatekeeper 组件之间的核心交互流程，从资源请求到策略评估的完整链路：

3.3 Admission Controller：策略执行的守门人

Admission Controller 是 Gatekeeper 与 Kubernetes API Server 交互的桥梁。它通过注册 ValidatingWebhookConfiguration 来拦截资源创建、更新、删除等操作。

• 工作模式： 仅支持 ValidatingAdmissionWebhook（验证准入），不支持 MutatingAdmissionWebhook（变更准入）。所有策略评估结果直接决定请求是否被允许。
• 超时控制： Webhook 调用必须在 30 秒内完成，否则 API Server 会超时并允许请求通过（fail-open 策略需谨慎配置）。
• 失败策略： 支持 Fail（严格模式，Webhook 不可用时拒绝所有请求）和 Ignore（宽松模式，Webhook 不可用时允许请求）。生产环境建议使用 Fail。
• 资源过滤： 可通过 namespaceSelector 和 objectSelector 精确控制哪些资源需要经过策略评估，降低集群控制面压力。

3.4 Constraint Framework：策略的生命周期管理者

Constraint Framework 是 Gatekeeper 的核心控制平面，负责将 ConstraintTemplate 实例化为可执行的 Constraint 对象，并管理其生命周期。

Constraint Framework 的核心工作流程：

1. 用户创建 ConstraintTemplate 对象，定义 Rego 策略逻辑和参数 schema。
2. Gatekeeper Controller 监听到 ConstraintTemplate 创建事件，自动生成对应的 CRD（Custom Resource Definition）。
3. 用户创建 Constraint 对象（即新 CRD 的实例），传入具体参数（如允许的仓库列表、必需的标签等）。
4. Controller 将 Constraint 编译为 OPA 可执行的规则，并注入到 OPA 引擎中。
5. Admission Controller 在收到资源请求时，从 OPA 引擎获取评估结果。

3.5 Constraint Template：策略逻辑的载体

ConstraintTemplate 是 Gatekeeper 策略能力的核心抽象。它使用 Rego 语言编写策略逻辑，并通过 OpenAPI v3 schema 定义可配置的参数。

一个典型的 ConstraintTemplate 结构如下：

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequiredlabels
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredLabels          # 生成的 CRD 名称
      validation:
        openAPIV3Schema:
          type: object
          properties:
            labels:
              type: array
              items:
                type: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredlabels

        violation[{"msg": msg}] {
          provided := {label | input.review.object.metadata.labels[label]}
          required := {label | label := input.parameters.labels[_]}
          missing := required - provided
          count(missing) > 0
          msg := sprintf("缺少必需的标签: %v", [missing])
        }

3.6 组件协作的完整数据流

下图展示了从 ConstraintTemplate 定义到最终策略评估的完整数据流，帮助理解三个组件如何协同工作：