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

做者 | Rafal 

导读：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；<br />
• 测试 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 --set service.port=string-
$ 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

本文转载自：RancherLabs，点击查看原文。

“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，作最懂云原生开发者的技术圈。”