3. OPA Gatekeeper 架构：组件、流程与调用链路
OPA Gatekeeper 是 Kubernetes 生态中最成熟的策略引擎之一，它通过 Admission Webhook 机制拦截资源请求，并利用 OPA/Rego 策略进行实时决策。理解其内部组件、请求流转路径以及 Webhook 调用链路，是优化策略缓存、降低 API 延迟的前提。
3.1 核心组件与职责
Gatekeeper 以一组 Kubernetes 原生 CRD 和控制器的方式运行，主要包含以下组件：
| 组件 | 类型 | 核心职责 |
|---|---|---|
| Gatekeeper Controller | Deployment (通常 2 副本) | 管理 CRD 状态、同步 ConstraintTemplate、处理 Webhook 请求 |
| OPA Sidecar / Library | 进程内嵌入 | 编译 Rego 策略、维护数据缓存、执行策略评估 |
| ValidatingWebhookConfiguration | K8s 资源 | 注册 Webhook 端点，定义拦截规则（资源类型、操作、命名空间） |
| ConstraintTemplate | CRD | 定义 Rego 策略模板，声明参数 schema 和 rego 代码 |
| Constraint | CRD 实例 | 实例化策略模板，绑定具体参数（如 allowedRegistries、requiredLabels） |
| Config 资源 | CRD | 配置数据同步范围（哪些命名空间、哪些资源类型需要缓存） |
关键设计点： Gatekeeper 并未将 OPA 作为独立 sidecar 进程运行，而是将 OPA 的评估引擎以 Go library 形式嵌入到 Controller 进程中。这种架构减少了进程间通信开销，但也意味着 Rego 缓存和内存管理完全由 Controller 进程承担。
3.2 Admission Review 请求流程
当用户执行 kubectl apply 或 API 调用创建/更新资源时，Kubernetes API Server 会触发 Admission Review 流程。Gatekeeper 作为 ValidatingAdmissionWebhook 参与其中，完整流程如下：
- API Server 接收请求：用户请求到达 API Server，经过认证、鉴权后进入 Admission 阶段。
- Webhook 匹配：API Server 根据 ValidatingWebhookConfiguration 中的
rules判断当前资源是否匹配（如：Pod、Namespace、Service 等）。 - 构造 AdmissionReview：API Server 将请求封装为
AdmissionReview对象，包含request.uid、request.object（新对象）、request.oldObject（更新时的旧对象）。 - HTTP 回调：API Server 通过 HTTPS POST 请求将 AdmissionReview 发送到 Gatekeeper 的 Webhook 端点（默认
/v1/admit）。 - Gatekeeper 处理：
- 反序列化 AdmissionReview。
- 提取资源对象和操作类型。
- 匹配所有已激活的 Constraint。
- 调用 OPA 引擎执行 Rego 策略评估。
- 收集所有违反策略的结果。
- 返回响应：Gatekeeper 构造响应 AdmissionReview，设置
response.allowed为 true/false，并在response.status.message中返回拒绝原因。 - API Server 执行或拒绝：根据 Webhook 响应，API Server 决定是否将资源写入 etcd。
延迟敏感点： 整个 Admission Review 流程是 同步阻塞 的。API Server 会等待所有 Webhook 返回结果（默认超时 30 秒）。如果 Gatekeeper 响应缓慢，会直接导致用户请求延迟增加，甚至触发 API Server 的 Webhook 超时重试。
3.3 Webhook 调用链路与数据流
为了更直观地展示请求在组件间的流转，下图描绘了从 API Server 到 Gatekeeper 内部再到 OPA 引擎的完整调用链路：
3.4 组件间数据同步机制
Gatekeeper 通过 Kubernetes Informer 机制监听集群内资源变化，并将数据同步到本地缓存。这一机制直接影响策略评估时的数据获取效率：
- ConstraintTemplate 同步：当用户创建/更新 ConstraintTemplate 时，Gatekeeper 控制器会重新编译 Rego 代码，生成新的 编译产物 并缓存。
- Constraint 同步：Constraint 实例的变化会触发策略索引重建，确保 Webhook 请求能快速匹配到正确的策略集合。
- 数据源同步：通过 Config 资源配置的
syncOnly字段，Gatekeeper 只同步指定的资源类型（如 Namespace、Pod、Node），减少内存占用和缓存更新频率。
常见陷阱： 如果 Config 资源中
syncOnly 配置了过多资源类型（如同步所有 Secrets），会导致 Gatekeeper 内存暴涨，并且每次资源变更都会触发缓存更新，增加 OPA 引擎的无效重算，最终拖慢 Webhook 响应时间。
3.5 多副本与 Webhook 负载均衡
在生产环境中，Gatekeeper 通常以 Deployment 多副本 方式部署。API Server 的 Webhook 配置默认使用 Service 进行负载均衡：
| 部署模式 | 负载均衡方式 | 缓存一致性 | 推荐场景 |
|---|---|---|---|
| 单副本 | 无 | 强一致（单进程） | 开发/测试环境 |
| 多副本（默认） | K8s Service 轮询 | 最终一致（各自缓存） | 生产环境（高可用） |
| 多副本 + Leader Election | Service + 选主 | 强一致（仅 Leader 处理） | 需要严格一致性的场景 |
性能建议： 多副本模式下，每个 Gatekeeper 实例维护独立的 Rego 缓存和数据缓存。当 ConstraintTemplate 更新时，所有实例都会重新编译，导致短暂的 CPU 峰值。建议将 副本数控制在 2~3 个，并配合 PodDisruptionBudget 避免滚动更新时所有实例同时重编译。