3. 规则复杂度定义
在 OPA 准入控制场景中，规则复杂度 是指一条 Rego 策略在解析、编译与评估过程中所消耗的计算资源（CPU、内存、时间）的度量。复杂度越高，每次准入请求的延迟就越长，甚至可能引发 kube-apiserver 超时。
理解复杂度的定义与度量指标，是进行性能调优和故障排查的第一步。
3.1 什么是规则复杂度
规则复杂度可以从两个维度理解：
- 静态复杂度：代码本身的嵌套深度、循环数量、数据源引用数量等，在编写阶段即可评估。
- 动态复杂度：运行时实际遍历的数据量、递归调用次数、缓存命中率等，与输入数据规模强相关。
一条低复杂度的规则通常满足：线性遍历、无深层嵌套、数据源引用少、无递归。高复杂度规则则往往包含多层 some 循环、深层 object.get 链、跨多个 bundle 的数据联合查询。
核心原则： 规则复杂度直接决定 OPA 的评估延迟。在准入控制路径上，每增加 1ms 的评估时间，都可能放大为整个集群的调度与响应瓶颈。
3.2 复杂度对性能的影响
复杂度对性能的影响主要体现在以下三个层面：
| 影响层面 | 具体表现 | 典型后果 |
|---|---|---|
| 编译阶段 | 规则嵌套过深导致编译时间指数增长 | OPA 启动慢、热更新延迟高 |
| 评估阶段 | 循环嵌套导致笛卡尔积式遍历 | 单次准入请求耗时 > 1s，触发 kube-apiserver 超时 |
| 内存占用 | 大量中间变量与临时对象堆积 | OPA 容器 OOMKilled，策略服务不可用 |
以实际生产数据为例：一条包含 3 层 some 嵌套的规则，当输入 Pod 包含 50 个容器时，评估时间可能从 2ms 飙升到 800ms，性能退化约 400 倍。
3.3 常见的复杂度指标
以下四个指标是衡量 OPA 规则复杂度的核心维度：
- 规则深度（Rule Depth）：规则中条件判断与函数调用的最大嵌套层数。深度每增加 1，评估路径数通常翻倍。
- 循环嵌套（Loop Nesting）：
some关键字或walk内置函数的嵌套层数。2 层以上嵌套极易产生 O(n²) 甚至 O(n³) 的复杂度。 - 数据源数量（Data Source Count）：单条规则中引用的
data、input、mock等数据源个数。每增加一个数据源，OPA 就需要多执行一次数据加载与索引查找。 - 递归调用（Recursion）：规则直接或间接调用自身。OPA 默认递归深度限制为 100，但深度超过 10 时性能已显著下降。
排查建议： 在 OPA 的
--format=json 输出中，可以查看 metrics 字段的 timer_rego_query_eval_ns 和 timer_rego_data_load_ns，快速定位高耗时规则。
3.4 指标量化参考
以下表格给出了生产环境中建议的复杂度阈值，超过该阈值时应主动进行规则重构：
| 指标 | 安全阈值 | 警告阈值 | 危险阈值 |
|---|---|---|---|
| 规则深度 | ≤ 3 层 | 4 ~ 6 层 | ≥ 7 层 |
| 循环嵌套 | ≤ 1 层 | 2 层 | ≥ 3 层 |
| 数据源数量 | ≤ 3 个 | 4 ~ 6 个 | ≥ 7 个 |
| 递归深度 | ≤ 5 层 | 6 ~ 15 层 | ≥ 16 层 |
注意： 上述阈值基于常规准入控制场景（输入对象大小 < 100KB）。如果集群中 Pod 或 CRD 资源定义特别庞大（例如包含大量注解或卷挂载），阈值应相应收紧 30%~50%。
3.5 复杂度指标的实际应用
在故障排查时，可以通过以下步骤快速定位高复杂度规则：
- 使用
opa eval --format=json --metrics 'data.kubernetes.admission'获取每条规则的评估耗时。 - 筛选出
timer_rego_query_eval_ns超过 100ms 的规则。 - 对候选规则逐条检查：规则深度、循环嵌套层数、引用的数据源列表。
- 使用
opa check --strict检测递归调用和未使用的变量。 - 根据上表阈值判断是否需要重构。
通过系统化地度量规则复杂度，团队可以在策略上线前就发现潜在的性能风险，避免将高延迟规则推送到生产集群。