2. OPA 基础架构：组件、数据流与决策缓存

在深入规则复杂度优化之前，必须理解 OPA 在 Kubernetes 环境中的物理组件构成、数据流动路径以及决策缓存的工作机制。本章将拆解 OPA 的三大核心组件——Rego 策略引擎、OPA Server 和 kube-mgmt，并分析 Admission Review 请求的完整生命周期。

2.1 OPA 核心组件

OPA 在 K8s 准入控制场景下由三个独立组件协同工作，每个组件承担不同的职责：

2.2 数据流：从 Admission Review 到决策返回

一个典型的 K8s 准入控制请求经过以下 6 个阶段：

1. API Server 拦截：用户通过 kubectl 或客户端发起资源创建/更新请求，API Server 的 Admission 链触发 MutatingWebhookConfiguration 或 ValidatingWebhookConfiguration。
2. 构造 AdmissionReview：API Server 将请求封装为 admission.k8s.io/v1 的 AdmissionReview 对象，通过 HTTPS 发送到 OPA Server 的 /v1/admit 端点。
3. OPA Server 接收：HTTP 处理器解析请求，提取 object、oldObject、operation、namespace 等字段，构造 Rego 输入文档 input。
4. 缓存查询：OPA Server 根据请求的 input 哈希值查询决策缓存。若命中且未过期，直接返回缓存结果，跳过 Rego 评估。
5. Rego 评估：缓存未命中时，Rego 引擎加载策略包和 data 文档，执行完整或部分评估，生成决策结果（allow/deny + 补丁）。
6. 响应返回：OPA Server 将决策结果封装为 AdmissionReview 响应，返回给 API Server。API Server 根据响应决定是否允许请求继续。

2.3 决策缓存机制

OPA Server 内置了基于 LRU（Least Recently Used）的决策缓存，用于避免重复评估相同输入的策略。缓存机制包含以下核心参数：

缓存键由 input 文档的完整 JSON 哈希值决定。这意味着：

• 两个完全相同的请求（包括 metadata、spec、status）会命中同一缓存条目。
• 即使只有少量字段不同（如 annotation 值），也会产生不同的缓存键，导致缓存未命中。
• 缓存条目在 TTL 过期后自动失效，下次相同请求将触发重新评估。

2.4 kube-mgmt 数据同步机制

kube-mgmt 作为 OPA 的 Sidecar 容器，负责将 K8s 集群状态同步到 OPA 的 data 文档中。其工作方式如下：

• 资源 Watch：kube-mgmt 通过 K8s 客户端库 Watch 指定的资源类型（如 Namespace、Pod、Service、Deployment 等）。
• 增量更新：当资源发生 ADDED/MODIFIED/DELETED 事件时，kube-mgmt 将变更数据推送到 OPA 的 /v1/data 端点，更新对应路径。
• 全量同步：启动时或 Watch 连接断开后，kube-mgmt 执行一次全量 LIST 操作，确保数据一致性。
• 命名空间过滤：可通过 --namespace 参数限制同步范围，减少不必要的数据传输和内存占用。

2.5 数据文档结构

kube-mgmt 同步的数据在 OPA 中以嵌套 JSON 结构组织，形成 data 文档。典型结构如下：

data = {
  "kubernetes": {
    "namespaces": [
      {"metadata": {"name": "default"}, ...},
      {"metadata": {"name": "kube-system"}, ...}
    ],
    "pods": [
      {"metadata": {"name": "nginx-xxx", "namespace": "default"}, ...}
    ],
    "services": [...],
    "deployments": [...]
  }
}

Rego 策略通过 data.kubernetes.namespaces 等路径访问这些数据。数据量越大，Rego 中的 data 查询开销越高，这也是规则复杂度优化的核心切入点之一。

2.6 组件间通信协议