4. 传统仓库的痛点分析：单点存储瓶颈、网络传输开销大、缺乏原生内容寻址、多集群分发效率低

在深入 OCI 分发与本地缓存加速方案之前，必须正视传统 Helm Chart 仓库（如 ChartMuseum、Harbor 的 Chart 模块、甚至简单的 Nginx 静态文件服务）在生产环境中暴露出的四大结构性痛点。这些痛点并非简单的配置问题，而是由架构设计本身决定的。

4.1 单点存储瓶颈：从磁盘到 I/O 的全链路压力

传统仓库通常将 Chart 包以 .tgz 文件形式存储在单一后端存储（本地磁盘、NFS 或对象存储桶）。当仓库成为团队唯一分发源时，所有 helm fetch、helm install 请求都汇聚于此，形成典型的单点瓶颈。

当团队规模超过 50 人，或 CI/CD 流水线频繁触发 helm dependency update 时，单点存储的磁盘队列深度会急剧上升，导致 Chart 拉取延迟从毫秒级恶化到秒级甚至分钟级。

4.2 网络传输开销大：重复拉取与全量下载

传统仓库在传输层面存在两个严重问题：缺乏增量传输和缺乏去重机制。每次 helm pull 都是完整的 .tgz 文件下载，即使只修改了 Chart 中的一个 YAML 文件，也必须重新下载整个包。

• 全量传输：一个 50MB 的 Chart 包，每次更新后 CI 需要完整下载 50MB，而非仅下载变更的 2KB 文件。
• 重复拉取：10 个集群同时部署同一版本 Chart，仓库需要发送 10 次完全相同的 50MB 数据流。
• 缺乏压缩感知：传统 HTTP 传输未针对 Helm Chart 的 .tgz 格式做二次压缩优化，带宽利用率低。

4.3 缺乏原生内容寻址：依赖易变标签与手动校验

传统仓库使用 Chart 名称 + 版本号 作为唯一标识，这本质上是基于标签的寻址方式，而非基于内容哈希的寻址。这种设计带来一系列安全与一致性问题：

相比之下，OCI 分发基于 Digest（SHA256 摘要） 进行内容寻址，每个 Chart 包的内容哈希是唯一的、不可变的。即使版本号相同，只要内容有差异，Digest 就会不同，从根本上杜绝了标签篡改风险。

4.4 多集群分发效率低：N 次拉取与跨区域延迟

在多集群、多区域的生产环境中，传统仓库的分发效率问题被急剧放大。每个集群都需要独立从中心仓库拉取 Chart，缺乏就近分发和缓存机制。

1. N 倍重复传输：5 个集群部署同一 Chart → 中心仓库出站流量放大 5 倍。
2. 跨区域延迟：中心仓库部署在 us-east-1，欧洲集群拉取 Chart 需要跨大西洋传输，延迟增加 200-300ms。
3. 缺乏本地缓存：每个集群的 Helm 客户端没有持久化缓存，每次部署都重新下载。
4. 仓库成为单点故障：中心仓库一旦不可用，所有集群的部署操作全部阻塞。

4.5 痛点总结：传统仓库的架构负债

综合以上分析，传统 Helm Chart 仓库的架构负债可以归纳为以下四个核心维度：