深度解读Helm 3: 犹抱琵琶半遮面
自去年年初开始放风Helm v3将要开始开发,到去年年底KubeConn 上海被一堆人追问到底啥时候发版本。今年五月份,Helm v3 终于发布了第一个alpha版本,让我们来一窥新版本的Helm 到底带来了什么。
Removal of Tiller
Helm 3最大的期待莫过于移除掉Tiller。很难想象一个开源项目,移除其中的一个核心组件会受到如此巨大的欢迎,其实毫不吝啬的说,Helm v3 alpha 1最大的功能就是去除了tiller。
由于历史原因,tiller 在集群应用版本管理和查询上扮演了重要的角色。但是随着RBAC等权限控制体系的组件完善,多租户和安全的需求日益兴起,tiller变得越来越不安全,社区在权限控制领域遇到了极大的阻碍。
移除tiller的好处主要有一下几点:
- 更加简单和灵活的架构
- 可以直接使用Kubernetes API交互
- 客户端渲染Chart, 在Kubernetes集群中存储release信息
- 客户使用壁垒更加的降低
CLI changes
helm delete
--->helm uninstall
: 曾经完全删除一个release需要helm delete xxx --purge
, 现在只需要uninstall
就可以,purge
会作为一个默认的行为helm inspect
--->helm show
: 这里可以查看Chart的具体信息helm fetch
--->helm pull
: 与docker pull
看齐,为下一步兼容registry 做铺垫,像拉取镜像一样拉取Chart部署
Breaking Changes (Warning)
-
Namespaces changes
Helm v2 只使用tiller 的namespace 作为release信息的存储,这样全集群的release名字都不能重复。Helm v3只会在release安装的所在namespace记录对应的信息,这样不同的namepsace就可以出现相同名字的release。
同样的原因,如果已经使用Helm v2创建了release,那么就无法使用helm v3来进行升级操作,因为无法将原来的单一namespace信息迁移到所属namespace 下。这一块的迁移功能,社区正在紧锣密鼓的开发中
-
Chart dependency management
- 老版本通过requirements.yaml和requirements.lock 来管理Chart的依赖,一个requirements.yaml 一般长相如下
- 新版本直接使用Chart.yaml 来记录依赖信息,新的Chart.yaml格式和requirements.yaml 基本相同
-
Generate Name
老版本Helm 可以直接安装chart 并不需要指定名称,Helm v3需要指定名称
Try
我们来试用一下Helm v3, 下载地址在这里https://github.com/helm/helm/releases/tag/v3.0.0-alpha.1。 为了防止与已经安装的Helm v2冲突,我们需要设置一下$HELM_HOME set an alternative location for Helm files. By default, these are stored in ~/.helm
,比如放到/tmp目录下。安装完毕后,helmv3 init
初始化一下就可以使用。
我们使用wordpress为例子
可以看到,目前已经存在的Chart可以完全无缝迁移到helmv3 ,完全兼容。只是不需要tiller 来协助安装。以前Helm v2存储的release 都在tiller 所在的namespace。
这就是Helm v2存储release 信息的地方,可以看到都在kube-system
命名空间下。
在看Helm v3,所有的信息都存储在release对应的namespace 下,而且以secret存储。这是v2和v3很不相同的地方。
Migrate from v2 to v3
- 针对目前已经存在的chart, helm v3可以无缝安装,无需迁移
- v2与v3可以共存,tiller 可以继续存在
-
已经使用v2安装的release,不能通过v3来升级,查看
Pushing Charts to OCI Registries
在如何远程托管Chart这件事上,经历了很多次的发展。最初是保存在本地,然后是打成压缩包,上传到oss 等远程存储,然后社区出现了Chartmuseum 这样的开源工具,提供公共的Chart托管。但是关于权限认证等方便并没有很好的解决方案。同时在后端存储方面,也没有能像Docker Registry 那样很好的节省空间避免重复存储的功能。
因此所有的目光都转向了Docker Registry,毕竟目前各大厂商都已经提供了镜像托管功能,能否复用这个能力来托管Chart是一个很好的方向。由此微软推出了 OCI Registry As Storage。根据镜像 OCI 标准规范,复用Registry 来存储Chart。这个目前已经集成到Helm v3试验版本里面。
我们来试用一下这个功能.
首先本地启动一个registrydocker run -dp 5000:5000 --restart=always --name registry registry:2
然后下载一个chart包helm fetch stable/wordpress
这样就完成了将Chart 推送到Registry的功能。这个功能目前处于实验性质,社区还是希望未来大家能够都转到这种存储方式上来。
What's Next
- alpha1: 移除Tiller, 提供Library charts, 存储格式改成secret, 开始OCI集成工作
- alpha2: 更好的 OCI 集成,Lua 模板支持
- alpha3: 重构更新策略(可能是客户端侧进行,也可能是服务端侧进行)
容器服务 Kubernetes 版(ACK)
阿里云容器服务是 Kubernetes 认证服务提供商(KCSP),国内唯一进入 Gartner 竞争格局的公有云容器平台。容器服务 Kubernetes 版(ACK)是安全稳定的企业级容器平台,支持高性能网络和存储,提供面向应用的异构资源统一管理,为企业上云提供最佳云原生支持。
本文作者:xianlubird
本文为云栖社区原创内容,未经允许不得转载。