你不得不了解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/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維護者來說，是一項重大利好。
 

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