OCI Registry 基础:OCI 标准简介、Helm Chart 推送至 OCI Registry 的原理与操作(helm push)
在云原生交付链路中,OCI Registry 正在取代传统的 ChartMuseum 和 HTTP Chart 存储,成为 Helm Chart 的标准分发后端。本节从 OCI 标准出发,逐步拆解 Helm Chart 推送至 OCI Registry 的核心原理与操作步骤。
2.1 OCI 标准简介
OCI(Open Container Initiative)是 Linux 基金会旗下的开放标准组织,定义了容器镜像和镜像仓库的行业规范。OCI Distribution Spec 描述了如何通过 HTTP API 对容器镜像进行推送、拉取、删除和列举,而 OCI Image Spec 则定义了镜像的层(Layer)与配置(Config)结构。
| 规范名称 | 核心内容 | 对 Helm 的意义 |
|---|---|---|
| OCI Distribution Spec | 定义 Registry API(Blob Upload、Manifest Push/Pull) | Helm 通过该 API 将 Chart 作为 OCI Artifact 推送 |
| OCI Image Spec | 定义镜像的层、配置、索引结构 | Helm Chart 被封装为符合 OCI Image Spec 的 Artifact |
| OCI Artifact 扩展 | 允许 Registry 存储非容器镜像的任意内容 | Helm Chart、CNAB、SBOM 等均可作为 Artifact 存储 |
关键认知: Helm v3.8+ 原生支持 OCI Registry,不再需要 ChartMuseum 或第三方插件。Chart 被存储为 OCI Artifact,其 Manifest 结构与容器镜像完全兼容,但层内容为 Chart 的压缩包(.tgz)。
2.2 Helm Chart 推送至 OCI Registry 的原理
Helm Chart 推送至 OCI Registry 的本质是将 Chart 打包为 OCI Artifact,并通过 Registry API 完成 Blob 上传与 Manifest 提交。整个过程分为三个核心阶段:
- Chart 打包与层拆分: Helm 将 Chart 目录压缩为
.tgz文件,作为 OCI 的单一层(Layer)。该层的 mediaType 为application/vnd.cncf.helm.chart.content.v1.tar+gzip。 - Manifest 构建: Helm 生成 OCI Manifest JSON,包含层引用(Digest)、配置信息(Chart.yaml 元数据)以及 Artifact 类型标记。Manifest 的 mediaType 为
application/vnd.cncf.helm.chart.config.v1+json。 - Registry API 交互: Helm 依次调用
POST /v2/<repo>/blobs/uploads/上传层 Blob,再调用PUT /v2/<repo>/manifests/<tag>提交 Manifest,完成推送。
2.3 Helm Chart 推送操作(helm push)
Helm v3.8+ 内置了 helm push 命令,无需额外安装插件。以下为完整的推送操作步骤:
2.3.1 前置条件
- Helm 版本 ≥ 3.8.0(推荐 3.12+)
- OCI Registry 已部署并支持 HTTPS(如 Harbor、Docker Hub、AWS ECR、Azure ACR)
- 已登录 Registry:
helm registry login <registry-url>
2.3.2 推送命令与参数
# 推送 Chart 到 OCI Registry
helm push mychart-0.1.0.tgz oci://registry.example.com/helm-charts
# 推送并指定版本(Chart 版本由 Chart.yaml 决定)
helm push mychart-0.1.0.tgz oci://registry.example.com/helm-charts --version 0.1.0
| 参数 | 说明 | 示例 |
|---|---|---|
oci:// |
指定使用 OCI 协议,而非 HTTP Chart 存储 | oci://harbor.example.com/library |
--version |
覆盖 Chart.yaml 中的版本号(可选) | --version 1.2.3 |
--insecure-skip-tls-verify |
跳过 TLS 验证(仅测试环境) | --insecure-skip-tls-verify |
2.3.3 推送后的 Registry 结构
推送成功后,Registry 中的存储结构如下:
registry.example.com/helm-charts/mychart
├── 0.1.0
│ ├── manifest (OCI Manifest)
│ └── blobs
│ └── sha256:abc123... (Chart .tgz 层)
└── 0.2.0
├── manifest
└── blobs
└── sha256:def456...
最佳实践: 建议在 Chart 的
Chart.yaml 中明确设置 annotations 字段,添加 org.opencontainers.image.source 和 org.opencontainers.image.version 标签,便于在 Registry UI 中识别 Chart 来源。
2.4 验证推送结果
推送完成后,可通过以下方式验证 Chart 是否成功存储:
- Registry UI 查看: 登录 Harbor / Docker Hub / ACR 控制台,确认 Chart 仓库下存在对应的 Artifact。
- Helm 拉取验证:
# 从 OCI Registry 拉取 Chart
helm pull oci://registry.example.com/helm-charts/mychart --version 0.1.0
# 查看 Chart 内容
tar -tzf mychart-0.1.0.tgz
常见问题: 如果推送时遇到
401 Unauthorized,请先执行 helm registry login 并确认凭据正确。如果遇到 405 Method Not Allowed,说明 Registry 未启用 OCI Artifact 支持(如某些旧版 Harbor 需开启 OCI 开关)。
2.5 OCI Registry 与传统 Chart 存储对比
| 对比维度 | 传统 ChartMuseum / HTTP 存储 | OCI Registry |
|---|---|---|
| 协议标准 | 自定义 HTTP API | OCI Distribution Spec(行业标准) |
| 存储结构 | 文件系统 + 索引 JSON | Blob + Manifest(与容器镜像一致) |
| 多租户 | 需额外配置 | 原生支持(Project / Namespace) |
| 镜像扫描集成 | 不支持 | 可与 Trivy / Clair 等扫描工具集成 |
| Helm 原生支持 | 需插件(helm-push) | Helm v3.8+ 内置支持 |
| 回滚能力 | 需手动管理版本 | 基于 Digest 的不可变引用,天然支持回滚 |