2. OPA Gatekeeper 架构深度解析：核心组件、数据流与策略执行链路

OPA Gatekeeper 是 Kubernetes 生态中实现可编程、声明式策略引擎的事实标准。它基于 OPA (Open Policy Agent) 的 Rego 语言，通过 Admission Webhook 和 Audit 两种机制，确保集群资源始终符合预定义的合规策略。本章将深入拆解其三大核心组件、关键数据流以及完整的策略执行链路，为后续诊断冷启动瓶颈奠定架构基础。

2.1 核心组件全景

Gatekeeper 由三个紧密协作的组件构成：Audit（审计）、Webhook（准入控制）和 Constraint Framework（约束框架）。它们共同实现了策略的“定义-执行-审计”闭环。

2.2 Constraint Framework：策略的声明式抽象

Constraint Framework 是 Gatekeeper 的“策略大脑”，它将复杂的 Rego 逻辑封装为可复用的模板，并通过 CRD 实例化。理解这一层是掌握 Gatekeeper 架构的关键。

• ConstraintTemplate：定义 Rego 策略逻辑的模板。包含一个 targets 字段（指定目标系统，如 admission.k8s.gatekeeper.sh）和 rego 代码块。模板中定义了 violation 规则，用于判断资源是否违规。
• Constraint：ConstraintTemplate 的实例化对象。通过 spec.match 字段指定策略生效的范围（如命名空间、资源类型、标签选择器），并通过 spec.parameters 传入模板所需的参数。
• Config：用于配置 Gatekeeper 自身行为的全局资源，例如指定哪些进程或命名空间需要被排除在审计之外。

# ConstraintTemplate 示例：禁止使用 latest 镜像标签
apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8sdisallowedtags
spec:
  crd:
    spec:
      names:
        kind: K8sDisallowedTags
      validation:
        openAPIV3Schema:
          type: object
          properties:
            tags:
              type: array
              items:
                type: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8sdisallowedtags

        violation[{"msg": msg}] {
          container := input.review.object.spec.containers[_]
          tags := input.parameters.tags[_]
          endswith(container.image, concat(":", [container.image, tags]))
          msg := sprintf("Image %v uses a disallowed tag %v", [container.image, tags])
        }
---
# Constraint 实例：禁止所有命名空间使用 latest 标签
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sDisallowedTags
metadata:
  name: block-latest-tag
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
  parameters:
    tags: ["latest"]

2.3 Webhook：实时准入控制链路

Webhook 是 Gatekeeper 最核心的执行路径，直接响应 API Server 的准入请求。其执行链路是诊断冷启动问题的焦点。

1. 请求拦截：Kubernetes API Server 根据 ValidatingWebhookConfiguration 配置，将匹配的资源变更请求（如创建 Pod）发送到 Gatekeeper 的 Webhook 端点。
2. 请求解析与缓存查询：Gatekeeper 解析 AdmissionReview 请求，提取资源对象（input.review.object）。随后，它查询本地缓存中的 Constraint 和 ConstraintTemplate 列表，确定哪些约束适用于当前请求。
3. Rego 评估：对于每个匹配的约束，Gatekeeper 将请求数据与 Rego 模板合并，调用 OPA 引擎执行策略评估。这是计算密集型阶段，也是冷启动时性能瓶颈的主要来源。
4. 响应聚合与返回：将所有约束的评估结果（允许/拒绝/警告）聚合成一个 AdmissionReview 响应。如果任何约束判定为 violation，则拒绝请求并返回错误信息。

2.4 Audit：周期性合规审计链路

Audit 组件负责对集群中已有资源进行合规性检查，确保没有“漏网之鱼”。它不阻塞资源变更，而是以报告形式呈现结果。

• 触发与调度：Audit 由 Gatekeeper Controller 中的定时器触发，默认周期为 60 秒。它通过 List 操作获取集群中所有匹配的资源。
• 批量评估：Audit 将获取到的资源列表与所有约束进行匹配，然后批量执行 Rego 评估。与 Webhook 的单次请求评估不同，Audit 需要处理大量资源，对 OPA 引擎的吞吐能力要求更高。
• 状态报告：评估完成后，Audit 会创建或更新 ConstraintPodStatus 和 ConstraintTemplatePodStatus 对象，记录每个约束的审计结果（violations 数量、上次审计时间等）。用户可以通过 kubectl describe constraint 查看审计状态。

2.5 数据流与策略执行链路总览

下图展示了 Gatekeeper 内部的数据流以及 Webhook 与 Audit 两条执行链路的关系。

2.6 核心组件交互时序

为了更清晰地理解组件间的协作关系，下表总结了 Webhook 和 Audit 两种场景下的关键交互步骤。