1. Helm 与 Chart 仓库基础：Helm 是什么、Chart 仓库的作用、OCI 与旧版仓库的区别
1.1 Helm：Kubernetes 的包管理器
Helm 是 Kubernetes 生态中最广泛使用的应用打包与部署管理工具，常被称为“Kubernetes 的 apt/yum/homebrew”。它通过 Chart（图表）这一标准化打包格式，将一组相关的 Kubernetes 资源（Deployment、Service、ConfigMap、Ingress 等）描述、版本化并组合在一起，实现一键安装、升级、回滚和卸载。
核心价值：将复杂的 Kubernetes YAML 管理从“手工拼凑”升级为“声明式、可复用、可版本化”的工程化流程。
1.2 Chart 仓库的作用
Chart 仓库（Chart Repository）是存储和分发 Helm Chart 的 HTTP/HTTPS 服务器。它本质上是一个 index.yaml 索引文件 + 一组打包后的 .tgz 文件。仓库的核心作用包括：
- 集中存储：将 Chart 包统一托管，避免散落在开发者本地或 Git 仓库中。
- 版本管理：支持语义化版本（SemVer），允许用户指定版本范围进行安装或升级。
- 依赖解析：Helm 在安装时自动从仓库拉取依赖的 Chart，实现复杂应用的组合部署。
- 团队协作：通过私有仓库实现企业内部 Chart 的共享与权限控制。
典型场景：一个微服务架构的应用，其基础中间件（Redis、MySQL）作为依赖 Chart 从公共仓库拉取，业务 Chart 从私有仓库拉取，Helm 自动完成依赖解析与安装顺序。
1.3 OCI 仓库与旧版仓库的区别
Helm v3.8+ 开始原生支持 OCI（Open Container Initiative） 标准仓库，将 Chart 作为 OCI 制品存储在容器镜像仓库（如 Harbor、Docker Hub、AWS ECR）中。这与传统的 Chart 仓库（基于 index.yaml 的 HTTP 服务器）有本质区别。
| 对比维度 | 旧版 Chart 仓库（index.yaml） | OCI 仓库（容器镜像仓库） |
|---|---|---|
| 存储结构 | 单一 index.yaml 索引 + 多个 .tgz 文件 |
每个 Chart 版本作为一个 OCI 制品（manifest + layers） |
| 认证机制 | 基本 HTTP 认证或自定义 | 标准 OCI 认证（docker login、bearer ） |
| 版本管理 | 依赖 index.yaml 中的条目，删除/覆盖操作不透明 |
基于 OCI 引用（registry/repo:tag），支持不可变标签和内容寻址 |
| 分发效率 | 每次拉取需下载整个 .tgz，不支持分层缓存 |
支持分层拉取（layer caching），仅下载变更层，显著加速大规模部署 |
| CDN 适配性 | 需额外配置反向代理缓存 .tgz 和 index.yaml |
天然适配 OCI 分发协议，可复用容器镜像 CDN 基础设施 |
| 工具生态 | 仅 Helm 原生支持，第三方工具需额外适配 | 兼容所有 OCI 标准工具（oras、crane、skopeo） |
迁移注意：OCI 仓库要求 Helm 版本 ≥ 3.8，且需要 Chart 开发者将 Chart 打包为 OCI 格式（
helm package + helm push）。旧版仓库中的 Chart 无法直接迁移，需重新推送。
1.4 Helm Chart 仓库架构对比（SVG）
下图展示了旧版 Chart 仓库与 OCI 仓库在存储和拉取流程上的核心差异：
1.5 为什么选择 OCI 仓库作为 CDN 加速目标
本课程后续的 CDN 配置实战将主要围绕 OCI 仓库展开，原因如下：
- 分层缓存效率高：CDN 节点可以缓存不变的 base layer，仅回源拉取变更的 diff layer，大幅降低回源带宽和延迟。
- 标准认证协议：OCI 的 Bearer 认证与 CDN 的鉴权配置（如阿里云 CDN 的 Referer/URL 鉴权）天然兼容。
- 多集群分发：在边缘 CDN 节点缓存 Chart 层，实现全球多 Kubernetes 集群的快速拉取。
- 工具链统一：与容器镜像共用同一套分发基础设施，降低运维复杂度。
实战前提：确保你的 Helm 版本 ≥ 3.8，并且目标容器镜像仓库（如 Harbor 2.4+、AWS ECR、Azure ACR）已开启 OCI 制品支持。