云原生交付加速！容器镜像服务企业版支持 Helm Chart

最新推荐文章于 2025-05-15 05:00:00 发布

原创最新推荐文章于 2025-05-15 05:00:00 发布 · 130 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#Image #权限管理 #控制台

随着Kubernetes成为云原生领域的标准，Helm作为一种应用包装方案，提供了Chart概念来简化Kubernetes资源的管理与分发。阿里云镜像服务企业版于2019年开放了HelmChart托管能力，支持企业级安全、权限管理和网络控制，旨在改善Chart的存储和管理。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

2018 年 6 月，Helm 正式加入了 CNCF 孵化项目；2018 年 8 月，据 CNCF 的调研表明，有百分之六十八的开发者选择了 Helm 作为其应用包装方案；2019 年 6 月，阿里云正式开放了开放云原生应用中心，为国内用户提供了海量的本地化 Helm Charts 应用；2019 年 7 月，阿里云镜像服务企业版正式开放了 Helm Charts 托管能力，允许企业版用户完成私有 Helm Charts 的推送、拉取以及批量管理。

Helm Chart，这究竟是什么呢？

伴随着云原生技术的迅速崛起，Kubernetes 已经成为事实上应用容器化平台的标准，成为了云原生领域的一等公民。它以一种声明式的容器编排与管理体系，让软件交付变得越来越标准化。具体来说，Kubernetes 提供了统一模式的 API，能以 YAML 格式的文件定义 Kubernetes 集群内的资源。这些资源的种类繁多，例如无状态应用的部署 Deployment，有状态应用的部署 StatefulSet，配置项 ConfigMap 等等。
这一些 YAML 格式的资源定义使得 Kubernetes 能轻松被上下游系统所集成，完成一系列原本需要用非标准化脚本、人工来完成的操作。但是这些文件的缺点也很明显，当我们想要创建一个资源时，往往要书写这样的一个 YAML 文件，这对于刚入门的开发者来说，存在着一些门槛。同时，当我们在大团队中协作，迭代这些资源时，就总觉得直接修改这样一个文件，会有冲突，无法回滚，难以溯源，边界模糊等问题。
因此云原生社区也衍生出了一系列最佳实践解决这些痛点，例如：

一些人将 YAML 文件都放到一个 Git 仓库中，依赖于 Git 的版本管理能力来管理线上架构，借助 CI 平台完成从 Git 仓库到线上环境的自动部署，人们把这称为 GitOps。GitOps 解决了 YAML 无法被版本化、变更无法溯源的问题。
kubernetes-sigs/kustomize 引入了 YAML 的公共模块机制，使得不同的 YAML 之间可以彼此引用依赖，使书写更加方便，维护起来更加清晰。
本文的主角 Helm 也是其中一个项目，它提出了 Chart 这个概念。一个 Chart 打包了一个应用的所有Kubernetes 资源的 YAML 文件，对外提供文档、配置项、版本等信息。而 Helm 本身则是一个命令行工具，我们可以使用 Helm 提交一个 Chart 到 Kubernetes 集群中，运行在集群中的控制器（v2 中为 tiller）会将 Chart 内的资源分别部署到 Kubernetes 集群中。

人们擅长于用已知来理解未知，我们就用下表来简单地介绍 Kubernetes 的世界中 Helm 的角色。

从现状来看，Helm 已经成为了应用分发界事实上的标准，但仍能听到一些反声音表示在生产环境使用，务必三思而后行：

Helm 的书写过程就是反人类的，Golang Template 的引入让事情变得更加复杂
Helm 生命周期管理能力很弱，无法处理复杂的部署
v2 版本中 Tiller 的引入，让 RBAC 变得毫无作用

Helm Chart 现状

根据 CNCF 在去年八月份的调研，有百分之六十八的人选择了 Helm Chart。不仅仅是开源软件的第三方交付，许多企业内部也借助 Helm 对于运行态 Release 的管理功能，满足其实现软件迭代过程中软件版本化、可追溯、可回滚方面的诉求。
在这些企业内部，用户使用 Chart 时面临着 Chart 存储方案的选择难题。我们做了一些调研，其实能被选择的方案并不多。一些用户将 Chart 直接放到 Git 仓库中进行版本化管理，一些客户则借助于开源软件来搭建一个类似于 Docker Hub 的 Chart 仓库来完成 Chart 托管，而有另外一些开源软件，则实现了一个 Helm 插件，可以将 Helm Chart 直接推送到类似于 OSS、S3 这样的对象存储中去。
然而对于企业级客户而言，这几种方案都面临着一些缺点。Git 仓库上手快，但其 Chart 内容版本和 Git 仓库分支没有关联；以开源软件搭建的 Chart 仓库又是另外一个需要维护的应用，增加了基础架构的依赖；Helm Chart 直接推送到 OSS 中，缺少企业级的权限管理，管理几乎都在命令行中完成。

镜像服务企业版 Helm Chart 托管功能开放

图为基于镜像服务企业版的软件迭代一站式解决方案

2019 年 7 月，阿里云镜像服务企业版正式开放了 Helm Chart 托管能力，提供了与容器镜像几乎一样的使用体验，理论上可以支持无限量的 Helm Chart 托管，提供 99.999999999% 的数据可靠性。类比于其他同类别的开源产品，我们做了深度改造，提供了如下的企业级特性：
安全合规
作为云服务提供，第一要务便是安全合规。在社区默认的例子里，Chartmuseum 使用了 Basic Auth 的认证，这种认证通常为固定的密码，无法接入阿里云 RAM 鉴权体系。在改造中，我们将 Chartmuseum 改成了 OAuth 2.0 Bearer Token 的鉴权机制，借鉴了 Registry 与 Docker Engine 之间的鉴权链路。同时开发了 Helm 客户端插件 AliyunContainerService/helm-acr 来自动完成鉴权，提升数据安全性和用户体验。

图为 OAuth2.0 鉴权链路，来自 chartmuseum/auth-server-example

RAM 鉴权管理体系
默认 Chartmuseum 的 UI 控制台无法完成一些复杂的操作。我们希望控制台可以允许：

多命名空间和 Chart 仓库管理
不同子账号对不同命名空间的权限管理
原生的 Chartmuseum 提供了 depth 的参数，用于控制租户级别：当 depth 等于 0 时，它表现为一个平面的仓库，可以堆放任意 Chart 版本。当 depth 等于 2 时，它增加了 org（组织），repo（仓库）的概念如下：

charts
├── org1
│   ├── repoa
│   │   └── nginx-ingress-0.9.3.tgz
├── org2
│   ├── repob
│   │   └── chartmuseum-0.4.0.tgz

为了让 Chartmuseum 的层级与我们现有的容器镜像保持统一，我们配置 depth 为 2，将组织映射到了我们的命名空间，将仓库映射到了我们的仓库，而这个仓库则是一片平地，可以推任意版本的 Chart。基于这部分关系映射后，我们通过回调改造将 Chartmuseum 的关系同步映射过来，如下表。结合阿里云的 RAM 鉴权策略，我们可以非常方便地对不同子账号、不同命名空间、仓库进行授权管理。

镜像服务企业版
├── 命名空间 A
│   ├── Chart 仓库 A
│   │   └── nginx-ingress-0.9.3.tgz
├── 命名空间 B
│   ├── Chart 仓库 B
│   │   └── chartmuseum-0.4.0.tgz

自定义网络 ACL
与企业版中提供的容器镜像服务一致，我们对 Helm Chart 托管能力的可访问入口也提供了自定义网络 ACL 的能力，您可以指定不同的 VPC、互联网 IP 地址访问到不同的企业版实例。

动手实践

容器镜像服务企业版支持 v2 版本的 Chart 安全托管，在企业版实例概览页开启 Charts 组件，待组件状态变为运行中，即可开始托管 Chart 类型仓库。

图为容器镜像服务企业版概览界面

安装并配置客户端
从官方下载需要的 Helm Chart 版本

# 解压缩
tar -zxvf helm-v2.14.2-linux-amd64.tgz

# 移动至指定位置
mv linux-amd64/helm /usr/local/bin/helm

使用 Helm Chart 托管功能时，请确保客户端为 v2 最新版本，可以通过 helm version -c 确认，建议使用 v2.14.2 版本。


# 安装 Helm 插件，请注意预先安装 git
helm plugin install https://github.com/AliyunContainerService/helm-acr

# 初始化

# 1. 如果您当前在容器服务集群节点上，默认已经有初始化完成的 tiller ，只需要初始化 client。可以使用 skip-refresh 命令避免访问 google Chart 源：
helm init --client-only --skip-refresh

# 2. 如果您当前在自建的 Kubernetes 集群节点上，并且希望避免访问 google Chart 源，可以使用以下命令：
helm init --skip-refresh

配置本地仓库映射
您需要指定一个本地仓库名称，映射到线上的某一个命名空间下的某一个 Chart 仓库。

export HELM_REPO_USERNAME='<企业版实例访问凭证中账号>';
export HELM_REPO_PASSWORD='<企业版实例访问凭证中密码>';

helm repo add <本地仓库名称> acr://<实例名称>-chart..cr.aliyuncs.com/<命名空间>/<Chart 仓库> --username ${HELM_REPO_USERNAME} --password ${HELM_REPO_PASSWORD}

推送 Chart
在简单配置企业版实例的访问凭证并打开网络访问控制后，就可以在终端推送 Chart 到 Chart 仓库中。


# 本地创建一个 Chart
helm create <Chart 名称>

# 推送 Chart 目录
helm push <Chart 名称> <本地仓库名称>

# 或者推送 Chart 压缩包
helm push <Chart 名称>-<Chart 版本>.tgz <本地仓库名称>

您可以在企业版控制台查看这些版本的大小信息并便捷管理版本，点击帮助文档，查看更多操作详情。

图为企业版 Chart 版本列表界面

未来

阿里云容器镜像服务（ACR）是国内最大的公有云镜像服务平台之一，支撑数万名开发者，十亿级别的镜像拉取，为开发者的每个应用镜像保驾护航。容器镜像服务企业版（ACR EE）是新推出面向企业级客户的安全托管平台，支持容器镜像及 Helm Chart 多种云原生应用资产管理，提供企业版实例独享部署、自定义网络访问控制及 P2P 大规模镜像分发等功能。未来我们将持续改进、优化 Helm Chart 托管能力，提供自定义接入域名，服务端 BYOK 存储加密等企业级功能。

原文链接
本文为云栖社区原创内容，未经允许不得转载。