你不得不瞭解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...

結 論

Helm 3的發佈，使得這一工具邁向一個新的階段。做爲用戶，我十分喜歡Helm如今只是一個單純的客戶端工具。做爲Chart維護者，Helm Hub以及分佈式倉庫的方法深得我心。我但願能在將來看到更多更有意思的改變。

若是你想了解Helm 3中的全部變化，請查看官方文檔：

https://helm.sh/docs/faq/#cha...

原文連接：

https://dzone.com/articles/he...