3. OPA 与 Rego 策略引擎：架构、语言与工作流
在 Kubernetes 准入控制场景中，OPA（Open Policy Agent）作为策略决策的核心组件，负责接收准入请求并基于 Rego 策略返回决策结果。理解 OPA 的架构、Rego 语言的核心概念以及 OPA 作为准入控制器的工作流，是排查策略缓存延迟故障的基础。
3.1 OPA 架构概览
OPA 采用解耦的决策架构，将策略决策从具体业务逻辑中抽离出来。其核心组件包括：
- 服务端（OPA Server）：运行 OPA 守护进程，提供 REST/gRPC 接口，接收查询请求并执行策略评估。
- 策略引擎（Rego Engine）：负责解析、编译和执行 Rego 策略，生成决策结果。
- 数据文档（Data Documents）：OPA 维护的全局数据缓存，包括从外部加载的 JSON/YAML 数据，如集群资源清单、用户信息等。
- 输入文档（Input Document）：每次查询时传入的临时数据，如 Kubernetes AdmissionReview 请求体。
- Bundle 系统：用于从远程 Bundle 服务器拉取策略包和数据，支持版本管理和热更新。
关键点：OPA 的决策完全基于输入文档和本地数据文档，不依赖外部服务，这保证了决策的低延迟和确定性。缓存延迟故障通常发生在数据文档更新或 Bundle 同步环节。
3.2 Rego 语言核心概念
Rego 是 OPA 专用的声明式策略语言，灵感来源于 Datalog。其核心概念包括：
| 概念 | 说明 | 示例 |
|---|---|---|
| 规则（Rule） | 策略的基本单元，定义决策逻辑 | allow { input.request.operation == "CREATE" } |
| 文档（Document） | OPA 中的数据集合，包括输入文档和数据文档 | input.request.object.metadata.name |
| 查询（Query） | 对 OPA 发起的决策请求，返回规则评估结果 | data.kubernetes.admission |
| 迭代（Iteration） | 使用 some 关键字遍历集合 |
some container; container := input.containers[_] |
| 内置函数（Built-in） | 预定义的函数，如字符串处理、时间比较 | count(input.containers) > 1 |
提示：Rego 策略的评估结果可以是布尔值（allow/deny）、对象（如 violations 列表）或任意 JSON 结构。在准入控制场景中，通常返回
allow 或包含拒绝原因的 deny 规则。
3.3 OPA 作为准入控制器的工作流
当 OPA 作为 Kubernetes 准入控制器（Admission Controller）运行时，其工作流分为以下步骤：
- 请求拦截：Kubernetes API Server 收到资源变更请求（CREATE/UPDATE/DELETE），根据配置的 MutatingWebhookConfiguration 或 ValidatingWebhookConfiguration 将请求转发给 OPA。
- 构建输入文档：OPA 将 AdmissionReview 请求体解析为
input文档，包含请求的元数据、操作类型、资源对象等。 - 策略评估：Rego 引擎加载预编译的策略包，结合输入文档和本地数据文档执行规则评估。
- 决策返回：OPA 将评估结果封装为 AdmissionReview 响应，返回给 API Server。响应中包含
allowed字段和可选的status信息。 - 执行动作：API Server 根据决策结果决定是否允许请求继续执行，或返回错误给客户端。
3.4 缓存机制与延迟风险
OPA 在准入控制场景中依赖多层缓存来提升性能，但缓存延迟也是故障的主要来源：
| 缓存层级 | 缓存内容 | 延迟风险 |
|---|---|---|
| 策略缓存 | 编译后的 Rego 策略 AST（抽象语法树） | 策略更新后缓存未刷新，导致旧策略生效 |
| 数据文档缓存 | 从外部加载的集群资源数据 | 数据同步延迟，导致决策基于过时信息 |
| Bundle 缓存 | 从 Bundle 服务器拉取的策略包 | Bundle 下载失败或版本回退，引发策略不一致 |
| 查询结果缓存 | 相同输入下的历史决策结果 | 缓存过期策略不当，导致重复评估或错误命中 |
注意：在排查缓存延迟故障时，应优先检查数据文档的更新时间戳和 Bundle 的同步状态。OPA 提供了
/v1/data 和 /v1/policies 接口用于诊断缓存状态。