你不得不瞭解 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 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的技術圈。」