4. Helm Chart 结构:Chart.yaml、values.yaml、templates 目录、子 chart
在 Helm 环境下进行 Rego 策略性能基准测试,首先需要深入理解 Helm Chart 的标准结构。Chart 是 Helm 的打包格式,本质上是一个遵循特定目录布局的文件集合。本章将拆解核心组件,为后续将 Rego 策略注入模板并执行测试奠定基础。
4.1 标准目录布局
一个典型的 Helm Chart 目录结构如下所示。理解每个文件与目录的职责,是编写可维护、可测试 Chart 的前提。
my-chart/
├── Chart.yaml # Chart 元数据定义
├── values.yaml # 默认配置值
├── values.schema.json # (可选) values 的 JSON Schema 校验
├── charts/ # 子 chart 依赖目录
│ └── sub-chart/
│ ├── Chart.yaml
│ ├── values.yaml
│ └── templates/
├── templates/ # 模板文件目录
│ ├── deployment.yaml
│ ├── service.yaml
│ ├── _helpers.tpl # 命名模板定义
│ └── tests/
│ └── test-connection.yaml
└── README.md # (可选) 使用说明
测试视角: 在性能基准测试中,
templates/ 目录是 Rego 策略注入与渲染压力的核心区域;values.yaml 则是控制测试变量(如副本数、资源限制)的入口。
4.2 Chart.yaml:Chart 的身份证
Chart.yaml 是每个 Chart 必须包含的元数据文件。它定义了 Chart 的名称、版本、API 版本等信息。Helm 在安装、升级、测试时首先解析此文件。
| 字段 | 说明 | 性能测试影响 |
|---|---|---|
apiVersion |
Chart API 版本(v2 为 Helm 3+) | 决定模板渲染引擎行为 |
name |
Chart 名称 | 用于 Release 命名与资源标签 |
version |
Chart 语义化版本 | 版本变更可能影响缓存命中率 |
dependencies |
子 chart 依赖列表 | 依赖解析增加渲染耗时 |
type |
application 或 library | library 类型不生成 Release,减少测试干扰 |
# Chart.yaml 示例
apiVersion: v2
name: rego-benchmark
description: A Helm chart for Rego policy performance testing
version: 0.1.0
type: application
dependencies:
- name: common
version: 1.0.0
repository: https://charts.example.com
4.3 values.yaml:配置的中央枢纽
values.yaml 定义了 Chart 的默认配置值。在性能测试中,它充当“参数面板”,允许测试人员在不修改模板的情况下,快速调整测试负载与策略参数。
- 全局值(global): 跨子 chart 共享的配置,如全局标签、镜像仓库地址。
- 组件值: 针对特定组件的配置,如
replicaCount、resources。 - 策略值: 自定义的 Rego 策略参数,如
policy.rules、policy.severity。
基准测试最佳实践: 将 Rego 策略的规则数量、复杂度、输入数据大小等变量抽象为 values 字段,通过脚本批量修改 values.yaml 来驱动性能测试矩阵。
# values.yaml 示例
replicaCount: 3
image:
repository: nginx
tag: latest
service:
port: 80
policy:
enabled: true
rules:
- "deny[msg] { input.request.method == \"DELETE\" }"
- "deny[msg] { input.request.path == \"/admin\" }"
inputSize: 1024 # 模拟输入数据大小(字节)
4.4 templates 目录:渲染引擎的核心
templates/ 目录存放 Go 模板文件,Helm 结合 values.yaml 和 Chart.yaml 渲染出最终的 Kubernetes 资源清单。这是 Rego 策略注入与性能测试的主战场。
| 文件类型 | 作用 | 性能测试关注点 |
|---|---|---|
*.yaml |
标准 Kubernetes 资源模板 | 模板复杂度影响渲染耗时 |
_helpers.tpl |
命名模板(可复用片段) | 频繁调用可能增加渲染时间 |
tests/ |
Helm 测试 Pod 定义 | 用于验证 Rego 策略执行结果 |
在 Rego 策略测试场景中,通常会在模板中嵌入 {{- .Values.policy.rules }} 或通过 ConfigMap 挂载策略文件,使策略成为模板渲染的一部分。
# templates/configmap.yaml 示例
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}-policy
data:
policy.rego: |
{{- range .Values.policy.rules }}
{{ . }}
{{- end }}
4.5 子 chart:依赖与模块化
子 chart 存放在 charts/ 目录下,用于实现模块化与依赖管理。在性能测试中,子 chart 会引入额外的渲染层级,影响整体测试性能。
- 依赖声明: 在 Chart.yaml 的
dependencies中声明,通过helm dependency update下载。 - 值覆盖: 父 chart 的 values 可以覆盖子 chart 的默认值,形成层级配置。
- 渲染顺序: Helm 先渲染子 chart,再渲染父 chart,子 chart 的输出可能被父 chart 引用。
性能陷阱: 过多的子 chart 层级或循环依赖会显著增加
helm template 的渲染时间。在基准测试中,应控制子 chart 深度不超过 3 层,并避免不必要的依赖。
4.6 结构关系总览
下图展示了 Helm Chart 各组件之间的数据流与依赖关系,帮助理解 Rego 策略在渲染过程中的位置。
4.7 性能测试视角下的结构要点
在进行 Rego 策略性能基准测试时,需要特别关注以下结构特性:
| 结构组件 | 测试指标 | 优化建议 |
|---|---|---|
| Chart.yaml 依赖 | 依赖解析时间 | 使用 helm dependency list 预解析,避免运行时下载 |
| values.yaml 层级 | 值合并耗时 | 扁平化结构,减少嵌套层级 |
| templates/ 数量 | 模板渲染吞吐量 | 合并小模板,减少文件 I/O |
| 子 chart 深度 | 递归渲染延迟 | 限制深度 ≤ 3,使用 library chart 替代 |
| Rego 策略嵌入方式 | 策略加载与执行时间 | 优先使用 ConfigMap 挂载,避免模板内联大策略 |
测试准备: 在开始基准测试前,建议使用
helm template --debug 验证 Chart 结构是否正确,并记录基础渲染耗时作为基线。