1. 课程导论：Rego策略在Helm中的重要性、性能基准测试的目标与范围

在云原生生态中，Helm 已成为 Kubernetes 应用打包与部署的事实标准。然而，随着安全左移与策略即代码（Policy-as-Code）的普及，如何在 Helm Chart 的渲染与部署阶段嵌入可编程的安全策略，成为保障集群合规性的关键挑战。Rego——作为 Open Policy Agent（OPA）的策略语言——凭借其声明式、可组合的特性，正被广泛用于定义 Helm 资源的安全边界。但 Rego 策略的执行效率直接影响 CI/CD 流水线的吞吐量，因此，建立一套系统化的性能基准测试体系，是确保策略安全性与交付速度兼得的前提。

1.1 Rego策略在Helm中的重要性

Helm 通过模板引擎将 Chart 渲染为 Kubernetes 清单，而 Rego 策略可以在渲染后、应用前对清单进行校验。这种“渲染时策略注入”模式带来了三个不可替代的价值：

• 合规左移： 在 Helm install/upgrade 之前拦截非合规配置，避免有缺陷的资源进入集群。
• 策略可编程： 利用 Rego 的完整逻辑表达能力（循环、模式匹配、聚合），实现远超静态 YAML lint 的复杂规则。
• 统一治理： 同一套 Rego 策略可同时用于 Helm、Kustomize、Admission Controller，降低策略碎片化。

以下表格对比了 Helm 环境下常见的策略执行方式，凸显 Rego 在灵活性与性能之间的独特位置：

1.2 性能基准测试的目标与范围

性能基准测试不是简单的“跑个分”，而是为了回答三个核心问题：

1. 延迟： 每条 Rego 策略在 Helm 渲染流程中增加了多少毫秒？
2. 吞吐： 在给定的 Chart 规模和策略复杂度下，每分钟能完成多少次合规校验？
3. 资源消耗： 策略执行对 CPU 和内存的峰值需求是多少？

本课程定义的基准测试范围覆盖以下维度：

• 策略复杂度： 从单条简单规则（如“禁止 privileged 容器”）到包含 50+ 条规则、跨资源引用的复合策略。
• Chart 规模： 从包含 5 个资源的微型 Chart 到包含 200+ 资源的大型生产级 Chart。
• 执行模式： 本地 OPA eval、容器化 OPA 沙箱、以及 Helm 插件内嵌执行。
• 数据输入： 静态清单 vs. 动态注入的外部数据（如集群节点标签、命名空间元数据）。

下图展示了本课程基准测试的整体范围与分层关系：

1.3 为什么需要专门的基准测试？

在 Helm 环境中，Rego 策略的性能表现与独立运行 OPA 时有显著差异，主要原因包括：

• 模板渲染开销： Helm 的 Go 模板引擎本身就有性能消耗，Rego 策略叠加在此之上，形成复合延迟。
• 数据格式转换： Helm 输出的 YAML 需转换为 OPA 可识别的 JSON 结构，序列化/反序列化成本不可忽略。
• 并发模型差异： Helm 插件通常以子进程方式调用 OPA，进程启动与通信开销远高于 OPA 的 HTTP API 模式。

1.4 课程受众与前置知识

本课程面向以下三类读者：