2. OPA与Rego基础回顾：OPA架构、Rego语言核心概念、策略执行模式
在深入K8s集群升级前的性能基准测试之前，必须牢固掌握OPA（Open Policy Agent）与Rego语言的核心机制。本章将系统回顾OPA的架构组件、Rego语言的三大核心概念（规则、查询、数据），以及策略在K8s环境中的执行模式。这些知识是后续构建性能测试场景、分析瓶颈和优化策略的基石。
2.1 OPA架构：解耦策略决策
OPA是一个开源的、通用策略引擎，其核心设计哲学是将策略决策从软件的业务逻辑中解耦出来。OPA本身不执行策略，而是提供一个统一的决策层，供其他服务（如K8s API Server、Envoy、Kong等）查询。
架构核心组件：
- OPA Agent（opa进程）： 核心引擎，负责加载策略、处理查询、缓存数据。
- Service API（REST/gRPC）： 对外暴露的决策接口，接收输入并返回决策结果。
- Bundle API： 从远程Bundle Server拉取策略和数据包，支持热加载。
- Data & Policies： 内存中的基础数据（JSON）和Rego策略规则。
2.2 Rego语言核心概念
Rego是OPA专用的声明式查询语言，灵感来源于Datalog。它不描述“如何做”，而是描述“数据应该是什么样子”。理解以下三个核心概念是编写高效策略的前提。
2.2.1 规则（Rules）
规则是Rego的基本构建块，用于定义策略逻辑。规则有两种主要类型：完整规则和部分规则。
| 类型 | 语法示例 | 说明 |
|---|---|---|
| 完整规则 | |
返回一个单一值（布尔、字符串等）。常用于定义最终决策。 |
| 部分规则 | |
生成一个集合或对象。常用于构建中间数据。 |
| 默认规则 | |
为规则提供默认值，防止未定义情况。 |
性能提示： 在性能基准测试中，部分规则的迭代次数和集合大小直接影响评估复杂度。避免在部分规则中使用不必要的全量遍历。
2.2.2 查询（Queries）
查询是向OPA引擎提出的问题。查询可以是完整查询（返回布尔值）或数据查询（返回数据片段）。
- 完整查询：
data.kubernetes.authz.allow— 返回true或false。 - 数据查询：
data.kubernetes.authz.allowed_roles— 返回角色集合。 - 带输入查询： 通过
input变量传入外部数据（如K8s Admission Review请求）。
2.2.3 数据（Data）
OPA将数据分为两类：基础数据和虚拟数据。
| 数据类别 | 来源 | 示例 | 性能影响 |
|---|---|---|---|
| 基础数据 | JSON/YAML文件、Bundle、API拉取 | 用户列表、命名空间白名单 | 加载时全量入内存，查询时只读 |
| 虚拟数据 | Rego规则计算得出 | 允许的命名空间集合 | 每次查询时动态计算，复杂度取决于规则 |
2.3 策略执行模式
在K8s环境中，OPA主要通过以下两种模式执行策略。理解这些模式对于设计性能测试场景至关重要。
2.4 关键概念总结表
| 概念 | 定义 | 在性能测试中的角色 |
|---|---|---|
| OPA Agent | 策略决策引擎 | 被测系统主体，监控其CPU、内存、延迟 |
| Rego规则 | 声明式策略逻辑 | 测试变量，规则复杂度直接影响评估时间 |
| Input | 查询时传入的外部数据 | 测试负载，模拟不同规模的K8s资源请求 |
| Data | OPA内存中的基础数据 | 测试背景，数据量大小影响缓存和查找性能 |
| 决策 | 策略评估结果（allow/deny） | 测试输出，验证正确性与响应时间 |
常见误区： 很多团队在升级前只测试了Admission Control的“允许”路径，忽略了“拒绝”路径。拒绝路径通常涉及更复杂的规则匹配和否定逻辑，可能比允许路径更消耗性能。务必在基准测试中覆盖两种决策结果。