你不得不了解Helm 3中的5个关键新特性

Helm是Kubernetes的一个软件包管理器。两个月前，它发布了第三个主要版本，Helm 3。在这一新版本中，有许多重大变化。本文将介绍我认为最关键的5个方面。

一、 移除了Tiller

Helm最终移除了其服务器端组件，Tiller。如今，它彻底没有代理。Tiller以前是一个运行在Kubernetes上的小型应用程序，它用于监听Helm命令并处理设置Kubernetes资源的实际工做。

这是Helm3中最重大的更改。为何Tiller的移除备受关注呢？首先，Helm应该是一种在Kubernetes配置上的模板机制。那么，为何须要在服务器上运行某些代理呢？

Tiller自己也存在一些问题，由于它须要集群管理员的ClusterRole才能建立。所以，假设你要在Google Cloud Platform中启动的Kubernetes集群上运行Helm应用程序。首先，你须要启动一个新的GKE集群，而后使用helm init初始化Helm，而后…发现它失败了。这种状况之因此会发生是由于，在默认状态下，你没有给你的kubectl上下文分配管理员权限。如今你了解到了这一点，开始搜索为分配管理员权限的magic命令。这一系列操做下来，也许你已经开始怀疑Helm是否真的是一个不错的选择。

此外，因为Tiller使用的访问权限与你在kubectl上下文中配置的访问权限不一样。所以，你也许可使用Helm建立应用程序，但你可能没法使用kubectl建立该程序。这一状况若是没排查出来，看起来感受像是安全漏洞。

幸运的是，如今Tiller已经被彻底移除，Helm如今是一个客户端工具。这一更改会致使如下结果：

• Helm使用与kubectl上下文相同的访问权限

• 你无需再使用helm init来初始化Helm

• Release Name 位于命名空间中

Helm 3一直保持不变的是：它应该只是一个在Kubernetes API上执行操做的工具。如此，若是你可使用纯粹的kubectl命令执行某项操做，那么也可使用helm执行该操做。

二、 分布式仓库以及Helm Hub

Helm命令能够从远程仓库安装Chart。在Helm 3以前，它一般使用预约义的中心仓库，但你也可以添加其余仓库。可是从如今开始，Helm将其仓库模型从集中式迁移到分布式。这意味着两个重要的改变：

• 预约义的中心仓库被移除

• Helm Hub（一个发现分布式chart仓库的平台）被添加到helm search

为了可以更好地理解这一改变，我给大家一个示例。在Helm 3以前，若是你想要安装一个Hazelcast集群，你须要执行如下命令：

$ helm2 install --name my-release stable/hazelcast

如今，这个命令不起做用了。你须要先添加远程仓库才能进行安装。这是由于这里再也不存在一个预约义中心仓库。要安装Hazelcast集群，你首先须要添加其仓库而后安装chart：

$ helm3 repo add hazelcast https://hazelcast.github.io/charts/
$ helm3 repo update
$ helm3 install my-release hazelcast/hazelcast

好消息是如今Helm 命令能够直接在Helm Hub中寻找Chart。例如，若是你想知道在哪一个仓库中能够找到Hazelcast，你只需执行如下命令便可：

$ helm3 search hub hazelcast

以上命令列出在Helm Hub中全部分布式仓库中名称中包含“hazelcast”的Chart。

如今，我来问你一个问题。移除掉中心仓库是进步仍是退步？这有两种观点。第一种是chart维护者的观点。例如，咱们维护Hazelcast Helm Chart，而Chart中的每一个更改都须要咱们将其传播到中心仓库中。这项额外的工做使得中心仓库中的许多Helm Chart没有获得很好地维护。这一状况与咱们在Ubuntu/Debian包仓库中所经历的很类似。你可使用默认仓库，但它经常只有旧的软件包版本。

第二种观点来自Chart的使用者。对于他们来讲，虽然如今安装一个chart比以前稍微困难了一些，但另外一方面，他们可以从主要的仓库中安装到最新的chart。

三、 JSON Schema 验证

从Helm 3开始，chart维护者能够为输入值定义JSON Schema。这一功能的完善十分重要，由于迄今为止你能够在values.yaml中放入任何你所需的内容，可是安装的最终结果可能不正确或出现一些难以理解的错误消息。

例如，你在port参数中输入字符串而不是数字。那么你会收到如下错误：

$ helm2 install --name my-release --set service.port=string-name hazelcast/hazelcast
Error: release my-release failed: Service in version "v1" cannot be handled as a Service:
v1.Service.Spec: v1.ServiceSpec.Ports: []v1.ServicePort: v1.ServicePort.Port: readUint32:
unexpected character: �, error found in #10 byte of ...|","port":"wrong-name|..., bigger
context ...|fault"},"spec":{"ports":[{"name":"hzport","port":"wrong-name","protocol":
"TCP","targetPort":"hazelca|...

你不得不认可这个问题难以分析和理解。

此外，Helm 3默认添加了针对Kubernetes对象的OpenAPI验证，这意味着发送到Kubernetes API的请求将会被检查是否正确。这对于Chart维护者来讲，是一项重大利好。

四、 Helm 测试

Helm测试是一个小小的优化。尽管微小，但它也许实际上鼓励了维护者来写Helm测试以及用户在安装完每一个chart以后执行helm test命令。在Helm 3以前，进行测试多少都显得有些奇怪：

一、 此前测试做为Pod执行（好像须要一直运行）；如今你能够将其定义为Job。

二、 测试Pod不会自动被移除（除非你使用magic flag –cleanup），因此默认状态下，没有任何技巧，对于既定的版本你不能屡次执行helm test。但幸运的是，如今能够自动删除测试资源（Pod、Job）。

固然旧的测试版本也并不是不能使用，只须要使用Pod并始终记得执行helm test –cleanup。但也不得不认可，这一改进有助于提高测试体验。

五、 命令行语法

最后一点是，Helm命令语法有所改变。从积极的一面来看，我认为全部的改变都是为了让体验更好；从消极的方面看，这一语法不与以前的版本兼容。所以，如今编写有关如何使用Helm安装东西的步骤时，须要明确指出所使用的命令是用于Helm 2仍是用于Helm 3。

举个例子，从helm install开始提及。如今版本名称已经成为必填参数，尽管在Helm 2中你能够忽略它，名称也可以自动生成。若是在Helm3中要达成相同的效果，你须要添加参数--generate-name。因此，使用Helm 2进行标准的安装应该以下：

$ helm2 install --name my-release hazelcast/hazelcast

在Helm 3中，须要执行如下命令：

$ helm3 install my-release hazelcast/hazelcast

还有另外一个比较好的改变是，删除Helm版本后，无需添加—purge。简单地输入命令helm uninstall <release-name>便可删除全部相关的资源。

还有一些其余改变，如一些命令被重命名（不过使用旧的名称做为别名），有一些命令则被删除（如 helm init）。若是你还想了解更多关于Helm 命令语法更改的信息，请参考官方文档：

https://helm.sh/docs/faq/#cli-command-renames

结 论

Helm 3的发布，使得这一工具迈向一个新的阶段。做为用户，我十分喜欢Helm如今只是一个单纯的客户端工具。做为Chart维护者，Helm Hub以及分布式仓库的方法深得我心。我但愿能在将来看到更多更有意思的改变。

若是你想了解Helm 3中的全部变化，请查看官方文档：

https://helm.sh/docs/faq/#changes-since-helm-2

原文连接：

https://dzone.com/articles/helm-3-top-five-improvements