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

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

1、 移除了 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 执行该操作。

2、 分布式仓库以及 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。

3、 JSON Schema 验证

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

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

$ helm2 install --name my-release --set service.port=string-name hazelcast/hazelcastError: 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|..., biggercontext ...|fault"},"spec":{"ports":[{"name":"hzport","port":"wrong-name","protocol":"TCP","targetPort":"hazelca|...

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

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

4、 Helm 测试

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

1、 此前测试作为 Pod 执行（好像需要一直运行）；现在你可以将其定义为 Job。

2、 测试 Pod 不会自动被移除（除非你使用 magic flag –cleanup），所以默认状态下，没有任何技巧，对于既定的版本你不能多次执行 helm test。但幸运的是，现在可以自动删除测试资源（Pod、Job）。

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

5、 命令行语法

最后一点是，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