Helm v3.0.0 Alpha 1 is coming!
Helm 作为 Kubernetes 体系的包管理工具,已经逐渐成为了事实上的应用分发标准。根据 2018 年 CNCF 的一项云原生用户调研,超过百分之六十八用户选择 Helm 来作为应用打包交付方式。在开源社区中,越来越多的软件被搬迁到 Kubernetes 集群上,它们中的绝大部分都是通过 Helm 来进行交付的。
Helm 当前的稳定版本为 v2.14.0
,最新发布的测试版本为 v3.0.0-alpha.1
。v3.x 的 alpha 版本可谓千呼万唤始出来,它带来了非常多的新特性及优化改进,让人无比兴奋,因此作此文以总结安利一番。
架构性变化 - 去除了 Tiller
在 Helm 2 中,一次基于 Helm 的软件交付会涉及到多个组件:
在 Helm 2 中,Tiller 是作为一个 Deployment
部署在 kube-system
命名空间中,很多情况下,我们会为 Tiller 准备一个 ServiceAccount
,这个 ServiceAccount
通常拥有集群的所有权限。用户可以使用本地 Helm 命令,*地连接到 Tiller 中并通过 Tiller 创建、修改、删除任意命名空间下的任意资源。
然而在多租户场景下,这种方式也会带来一些安全风险,我们即要对这个 ServiceAccount
做很多剪裁,又要单独控制每个租户的控制,这在当前的 Tiller 模式下看起来有些不太可能。
于是在 Helm 3 中,Tiller 被移除了。新的 Helm 客户端会像 kubectl
命令一样,读取本地的 kubeconfig
文件,使用我们在 kubeconfig
中预先定义好的权限来进行一系列操作。这样做法即简单,又安全。
虽然 Tiller 文件被移除了,但 Release
的信息仍在集群中以 ConfigMap
的方式存储,因此体验和 Helm 2 没有区别。
Tiller 变更引入的新变化 - Release 不再是全局资源
在 Helm 2 中,Tiller 自身部署往往在 kube-system
下,虽然不一定是 cluster-admin
的全局管理员权限,但是一般都会有 kube-system
下的权限。当 Tiller 想要存储一些信息的时候,它被设计成在 kube-system
下读写 ConfigMap
。
在 Helm 3 中,Helm 客户端使用 kubeconfig
作为认证信息直接连接到 Kubernetes APIServer,不一定拥有 cluster-admin
权限或者写 kube-system
的权限,因此它只能将需要存储的信息存在当前所操作的 Kubernetes Namespace 中,继而 Release
变成了一种命名空间内的资源。
Values 支持 JSON Schema 校验器
Helm Charts 是一堆 Go Template 文件、一个变量文件 Values 和一些 Charts 描述文件的组合。Go Template 和 Kubernetes 资源描述文件的内容十分灵活,在开发迭代过程中,很容易出现一些变量未定义的问题。Helm 3 引入了 JSON Schema 校验,它支持用一长串 DSL 来描述一个变量文件的格式、检查所有输入的变量的格式。
当我们运行 helm install
、 helm upgrade
、 helm lint
、 helm template
命令时,JSON Schema 的校验会自动运行,如果失败就会立即报错。
一个来自官方的例子
当我们指定一个 JSON Schema 文件为下述时:
{
"$schema": "http://json-schema.org/draft-07/schema#",
"properties": {
"image": {
"description": "Container Image",
"properties": {
"repo": {
"type": "string"
},
"tag": {
"type": "string"
}
},
"type": "object"
},
"name": {
"description": "Service name",
"type": "string"
},
"port": {
"description": "Port",
"minimum": 0,
"type": "integer"
},
"protocol": {
"type": "string"
}
},
"required": [
"protocol",
"port"
],
"title": "Values",
"type": "object"
}
我们看到 JSON Schema 描述文件中指定了 protocol
和 port
为必填字段,于是我们可以指定一个 values.yaml 如下:
name: frontend
protocol: https
port: 443
但事实上,我们也可以指定为如下,因为我们可以在 helm 命令行传入变量参数,例如 helm install --set port=443
name: frontend
protocol: https
试验性功能 - 推送 Charts 到容器镜像仓库中
互联网上有一些 Helm Charts 托管平台,负责分发常见的开源应用,例如 Helm Hub、KubeApps Hub。
在企业环境中,用户需要私有化的 Helm Charts 托管。最常见的方案是部署 ChartMuseum,使其对接一些云存储。当然也有一些较为小众的方案,比如 [App-Regsitry]() 直接复用了 Docker 镜像仓库 Registry V2,再比如 helm-s3 直接通过云存储 S3 存取 Charts 文件。
如今在 Helm 3,Helm 直接支持了推送 Charts 到容器镜像仓库的能力,希望支持满足 OCI 标准的所有 Registry。但这部分还没有完全被开发完,会在未来的 alpha 版本中被完善。
代码复用 - Library Chart 支持
Helm 3 中引入了一种新的 Chart 类型,名为 Library Chart
。它不会部署出一些具体的资源,只能被其他的 Chart 所引用,提高代码的可用复用性。当一个 Chart 想要使用该 Library Chart
内的一些模板时,可以在 Chart.yaml
的 dependencies
依赖项中指定。
其他的一些变化
- Go Import 的路径由
k8s.io/helm
变成了helm.sh/helm
。 - 简化了 Chart 内置变量
Capabilities
的一些属性[2]。 -
helm install
不再默认生成一个 Release 的名称,除非指定了--generate-name
。 - 移除了用于本地临时搭建 Chart Repository 的
helm serve
命令。 -
helm delete
更名为helm uninstall
,helm inspect
更名为helm show
,helm fetch
更名为helm pull
,但以上旧的命令当前仍能使用。 -
requirements.yaml
被整合到了Chart.yaml
中,但格式保持不变。
现在怎么办呢?
当前 Helm 3 仍在紧张而有序地开发当中,如果需要在生产环境使用,Helm 2 看起来会更加稳妥一些。
如果您恰好需要私有的 Helm Chart 仓库,欢迎申请试用阿里云容器镜像服务企业版(ACR EE),我们即将上线 Helm Charts 托管功能。
阿里云容器镜像服务(ACR)是国内最大的公有云镜像服务平台,支撑数万名开发者,共计十亿级别的镜像拉取,为开发者的每个应用镜像保驾护航。容器镜像服务企业版(ACR EE)是新推出的面向企业级客户的安全镜像托管平台,支持镜像服务企业版实例独享部署、OSS Bucket 独享加密存储、自定义网络访问控制及 P2P 大规模镜像分发功能。点击了解产品详情 https://www.aliyun.com/product/acr
Reference
[1] CNCF Survey: Use of Cloud Native Technologies in Production Has Grown Over 200% https://www.cncf.io/blog/2018/08/29/cncf-survey-use-of-cloud-native-technologies-in-production-has-grown-over-200-percent/
[2] The Chart Template Developer’s Guide https://v3.helm.sh/docs/chart_template_guide/#built-in-objects