📚 课程目录第4章 Helm Chart仓库架构

4. Helm Chart 仓库架构：存储结构、index.yaml、tgz 包与签名机制

理解 Helm Chart 仓库的底层架构，是配置 CDN 加速的前提。仓库本质上是一个静态 HTTP 服务器，其核心由 tgz 包、index.yaml 索引文件和可选的签名文件组成。本节将拆解这三部分的结构与协作关系。

4.1 仓库物理存储结构

一个标准的 Helm Chart 仓库在服务器上的目录结构如下：

my-helm-repo/
├── index.yaml
├── mychart-1.0.0.tgz
├── mychart-1.0.0.tgz.prov
├── mychart-1.1.0.tgz
├── mychart-1.1.0.tgz.prov
├── anotherchart-0.2.0.tgz
└── anotherchart-0.2.0.tgz.prov

文件/目录	说明	是否必需
`index.yaml`	仓库的“目录”和“元数据索引”，记录所有 Chart 版本、URL、校验和等信息	是
`*.tgz`	Chart 的打包压缩文件，包含 Chart.yaml、模板、values 等	是
`*.tgz.prov`	Chart 的签名证明文件，用于验证包完整性和发布者身份	否

CDN 加速要点： CDN 节点只需缓存 index.yaml 和 *.tgz 文件。*.prov 文件体积小且访问频率低，可按需回源。

4.2 tgz 包：Chart 的交付单元

每个 .tgz 文件都是一个完整的 Helm Chart 发布版本。解压后内部结构如下：

mychart-1.0.0/
├── Chart.yaml          # Chart 元数据（名称、版本、依赖等）
├── values.yaml         # 默认配置值
├── values.schema.json  # （可选）values 的 JSON Schema 校验文件
├── charts/             # （可选）子 Chart 依赖包
│   └── subchart-0.1.0.tgz
├── templates/          # Kubernetes 资源模板（Go 模板语法）
│   ├── deployment.yaml
│   ├── service.yaml
│   └── _helpers.tpl
├── templates/NOTES.txt # 安装后的使用说明
├── README.md           # Chart 使用文档
└── crds/               # （可选）CRD 定义文件

  CDN 缓存策略： tgz 包通常较大（几百 KB 到几十 MB），且内容不可变（版本号唯一）。建议设置 长期缓存（如 max-age=31536000），利用 CDN 边缘节点大幅减少回源流量。

4.3 index.yaml：仓库的“大脑”

index.yaml 是 Helm 客户端与仓库交互的核心文件。它记录了仓库中所有 Chart 的版本、下载地址、校验和、依赖关系等信息。Helm 通过解析此文件来决定下载哪个版本。

一个典型的 index.yaml 结构如下：

apiVersion: v1
entries:
  mychart:
  - apiVersion: v2
    appVersion: "1.16.0"
    created: "2024-01-15T10:00:00Z"
    description: A Helm chart for Kubernetes
    digest: "sha256:abc123def456..."
    name: mychart
    type: application
    urls:
    - https://repo.example.com/mychart-1.0.0.tgz
    version: 1.0.0
  - apiVersion: v2
    appVersion: "1.17.0"
    created: "2024-02-20T14:30:00Z"
    description: A Helm chart for Kubernetes
    digest: "sha256:789ghi012jkl..."
    name: mychart
    type: application
    urls:
    - https://repo.example.com/mychart-1.1.0.tgz
    version: 1.1.0
  anotherchart:
  - apiVersion: v2
    appVersion: "0.2.0"
    created: "2024-03-10T09:00:00Z"
    description: Another chart
    digest: "sha256:mno345pqr678..."
    name: anotherchart
    type: application
    urls:
    - https://repo.example.com/anotherchart-0.2.0.tgz
    version: 0.2.0
generated: "2024-03-10T09:00:00Z"

字段	含义	CDN 加速关注点
`entries`	Chart 名称到版本列表的映射	—
`urls`	Chart tgz 包的下载地址（可多个）	必须指向 CDN 域名，否则 Helm 会直接回源
`digest`	tgz 包的 SHA-256 校验和	用于验证缓存文件完整性，防止 CDN 投毒
`created`	版本发布时间	可用于 CDN 缓存键或预热策略

关键配置： 如果使用 CDN 加速，务必修改 index.yaml 中的 urls 字段，将原始仓库地址替换为 CDN 加速域名地址。否则 Helm 客户端仍会从源站下载 tgz 包，CDN 无法生效。

4.4 签名机制：.prov 文件与完整性验证

Helm 支持使用 GPG 对 Chart 进行签名，生成 .tgz.prov 证明文件。该机制确保：

完整性： tgz 包未被篡改。
来源可信： Chart 由已知的发布者签名。

签名验证流程：

Chart 维护者使用私钥对 tgz 包签名，生成 .prov 文件。
用户通过 helm verify 命令，使用公钥验证 .tgz 与 .prov 的匹配性。
验证通过后，Helm 才会安装该 Chart。

  CDN 场景下的签名： 即使 tgz 包被 CDN 缓存，签名机制仍能保证文件未被中间人篡改。建议所有生产环境 Chart 都启用签名，CDN 节点无需特殊处理 .prov 文件，只需按普通静态文件缓存即可。

4.5 架构总览：仓库组件协作关系

下图展示了 Helm Chart 仓库的核心组件及其在 CDN 加速环境下的协作流程：

4.6 关键总结

index.yaml 是仓库的入口，Helm 客户端通过它找到所有 Chart 版本和下载地址。
tgz 包 是实际交付的 Chart 内容，体积大、不可变，适合 CDN 长期缓存。
签名机制 通过 .prov 文件提供端到端的安全验证，CDN 无需特殊处理。
CDN 加速的核心在于：将 index.yaml 中的 urls 指向 CDN 域名，并合理配置缓存策略。