2. Gatekeeper 核心架构：OPA 引擎、Admission Webhook、约束模板与约束的关系
Gatekeeper 是 Kubernetes 生态中最成熟的 策略引擎，其核心架构由四个关键组件构成：OPA 策略引擎、Admission Webhook、ConstraintTemplate（约束模板） 与 Constraint（约束）。理解这四个组件之间的协作关系，是编写、调试和评审 Gatekeeper 策略的基础。
下图展示了 Gatekeeper 在 Kubernetes API 请求链路中的核心位置与组件交互流程：
2.1 组件角色与职责
| 组件 | 角色 | 关键职责 |
|---|---|---|
| OPA 引擎 | 策略决策核心 | 加载 Rego 策略、评估输入、返回决策结果 |
| Admission Webhook | 请求拦截器 | 拦截匹配的 API 请求，构造 AdmissionReview 并转发给 OPA |
| ConstraintTemplate | 策略模板定义 | 声明 Rego 逻辑、参数 schema、CRD 生成规则 |
| Constraint | 策略实例化 | 提供具体参数值，绑定到目标资源或命名空间 |
2.2 约束模板（ConstraintTemplate）与约束（Constraint）的关系
这是 Gatekeeper 策略体系中最重要的抽象关系，理解它才能正确编写和复用策略。
核心原则：ConstraintTemplate 是“类”，Constraint 是“对象”。
ConstraintTemplate 定义了策略的通用逻辑（Rego 代码）和可配置参数（parameters）；Constraint 则通过提供具体的参数值，将模板实例化为一条可执行的策略规则。
2.3 约束模板的组成结构
一个完整的 ConstraintTemplate 包含三个核心部分：
- CRD Schema 定义（spec.crd.spec）：声明 Constraint 对象可以接受哪些参数，包括参数名称、类型、默认值等。
- Rego 策略逻辑（spec.targets[0].rego）：使用 Rego 语言编写的策略评估规则，是策略的核心决策逻辑。
- Rego 库（spec.targets[0].libs）：可选的公共 Rego 函数库，用于减少重复代码。
最佳实践：ConstraintTemplate 中的 Rego 代码应保持通用性，将可变部分（如标签名、端口号、镜像仓库地址）暴露为 parameters，由 Constraint 实例化时传入。这样可以实现“一次编写，多处复用”。
2.4 约束的匹配机制
Constraint 通过 spec.match 字段控制策略的生效范围，支持以下匹配维度：
| 匹配维度 | 字段路径 | 示例值 |
|---|---|---|
| 资源类型 | spec.match.kinds |
[{apiGroups: [""], kinds: ["Pod"]}] |
| 命名空间 | spec.match.namespaces |
["production", "staging"] |
| 命名空间选择器 | spec.match.namespaceSelector |
{matchLabels: {env: "prod"}} |
| 标签选择器 | spec.match.labelSelector |
{matchLabels: {app: "web"}} |
| 排除命名空间 | spec.match.excludedNamespaces |
["kube-system", "gatekeeper-system"] |
| 作用域 | spec.match.scope |
Namespaced / Cluster / * |
2.5 策略评估的完整链路
当 Kubernetes API Server 收到资源创建或更新请求时，Gatekeeper 的评估链路如下：
请求处理链路（7 步）：
- 客户端 发送 kubectl apply / API 请求
- API Server 执行身份认证与鉴权
- API Server 匹配 ValidatingAdmissionWebhook 配置，构造 AdmissionReview 对象
- Gatekeeper Webhook 接收 AdmissionReview，提取资源对象与操作类型
- OPA 引擎 加载所有匹配的 Constraint（已实例化的策略），执行 Rego 评估
- OPA 引擎 返回 AdmissionResponse（允许 / 拒绝 + 消息）
- API Server 根据响应决定是否持久化资源，并将结果返回客户端
安全冷启动风险提示：在 Gatekeeper 首次部署或大规模更新 ConstraintTemplate 时，OPA 引擎需要重新编译 Rego 策略。如果此时大量请求涌入，可能导致 Webhook 响应超时（默认 30 秒），进而影响整个集群的 API 可用性。第 3 章将详细讨论冷启动的优化策略。
2.6 组件关系总结
四个核心组件的关系可以用一句话概括：Admission Webhook 负责拦截，OPA 引擎负责决策，ConstraintTemplate 负责定义策略逻辑，Constraint 负责将策略逻辑绑定到具体资源并传入参数。
在实际运维中，策略评审的重点应放在：
- ConstraintTemplate 中 Rego 逻辑的正确性与性能
- Constraint 中 match 范围的合理性（避免过宽或过窄）
- parameters 的默认值是否安全
- enforcementAction 的设置（deny / dryrun / warn）是否符合预期