2. OPA Gatekeeper 架构解析：核心组件、工作流程与数据流
在生产环境中实施镜像拉取流量控制，首先需要理解 OPA Gatekeeper 的底层架构。本章将拆解其三大核心组件（OPA、Gatekeeper、Admission Webhook），梳理一次准入请求的完整生命周期，并通过数据流图展示组件间的协作关系。
2.1 核心组件
OPA Gatekeeper 并非单一二进制，而是由三个独立但紧密协作的组件构成。下表总结了各组件的职责与部署形态：
| 组件 | 职责 | 部署形态 | 关键接口 |
|---|---|---|---|
| OPA（Open Policy Agent） | 通用策略引擎，执行 Rego 策略并返回决策 | 作为 sidecar 或独立 DaemonSet 运行 | REST API（/v1/data） |
| Gatekeeper | Kubernetes 原生策略控制器，管理约束模板与约束实例 | 以 Deployment 形式运行在集群内 | Kubernetes API（CRD） |
| Admission Webhook | Kubernetes API Server 的准入扩展点，拦截资源请求 | 由 Gatekeeper 自动注册的 MutatingWebhookConfiguration / ValidatingWebhookConfiguration | HTTPS / JSON |
关键理解：Gatekeeper 是 Kubernetes 与 OPA 之间的“翻译层”。它负责将 Kubernetes 的 CRD 资源（ConstraintTemplate、Constraint）转换为 OPA 可执行的 Rego 查询，并将 OPA 的决策结果映射为 Kubernetes 准入响应。
2.2 组件协作关系图
下图展示了三个组件在集群内的部署位置与通信链路。注意 OPA 通常以 sidecar 模式与 Gatekeeper 容器共享同一个 Pod。
2.3 工作流程：一次准入请求的完整生命周期
当用户执行 kubectl apply 创建包含镜像拉取配置的 Pod 时，Gatekeeper 的准入控制流程分为以下六个步骤：
- 请求触发：用户或 CI/CD 系统向 Kubernetes API Server 发送资源创建/更新请求。
- 准入拦截：API Server 根据注册的
ValidatingWebhookConfiguration，将请求序列化为 AdmissionReview JSON，发送至 Gatekeeper 的 Webhook 端点。 - 约束匹配：Gatekeeper 控制器根据请求中的资源类型（如 Pod）、命名空间标签等，匹配已定义的
Constraint实例。 - 策略查询：Gatekeeper 将匹配到的约束与对应
ConstraintTemplate中的 Rego 代码组合，构造查询请求，发送给同 Pod 内的 OPA sidecar。 - 决策执行：OPA 引擎执行 Rego 策略，检查请求中的
imagePullSecrets、image字段等，返回true（允许）或false（拒绝）及可选消息。 - 响应返回：Gatekeeper 将 OPA 的决策封装为 AdmissionReview 响应，返回给 API Server。若拒绝，API Server 会终止请求并返回错误给客户端。
性能要点：整个流程在 API Server 超时时间内完成（默认 30 秒）。OPA 引擎通常能在毫秒级返回决策，Gatekeeper 的缓存机制进一步减少了重复查询的开销。
2.4 数据流图：镜像拉取权限检查的详细路径
针对“控制镜像拉取流量”这一具体场景，下图展示了数据在组件间的流动细节，重点关注 imagePullSecrets 和 image 字段的传递路径：
2.5 组件间通信协议与端口
理解组件间的通信方式有助于排查网络策略和证书问题。下表列出了关键通信链路：
| 通信方向 | 协议 | 默认端口 | 认证方式 |
|---|---|---|---|
| API Server → Gatekeeper Webhook | HTTPS | 443 | TLS 证书（由 Gatekeeper 自动管理） |
| Gatekeeper → OPA sidecar | HTTP | 8181 | 本地回环，无额外认证 |
| Gatekeeper → Kubernetes API | HTTPS | 6443 | ServiceAccount |
安全注意：Gatekeeper 与 OPA 之间的通信默认使用 HTTP 且无认证，因为它们运行在同一个 Pod 内，通过 localhost 通信。如果修改部署拓扑将 OPA 独立部署，必须启用 TLS 和认证机制。
2.6 架构设计要点总结
- 松耦合：Gatekeeper 与 OPA 通过 REST API 通信，可独立升级或替换策略引擎。
- 缓存先行：Gatekeeper 维护了约束、模板和命名空间的本地缓存，避免每次请求都查询 Kubernetes API。
- 失败关闭：当 OPA 不可用时，Gatekeeper 默认行为是拒绝所有请求（fail-closed），防止策略绕过。
- 审计能力：除了实时准入，Gatekeeper 还支持定期审计（audit），扫描集群中已有资源是否违反当前约束。