恕我直言，對Helm大家還是要三思而後用

作者 | Bart?omiej Antoniak

譯者 | 謝麗

Helm 是 Kubernetes 的包管理器。它可以大幅簡化發布過程，但有時候也會帶來問題。近日，Helm 已經正式提升為頂級的 CNCF 項目，並且在社區得到了廣泛的應用。這說明 Helm 確實是個不錯的項目了，但我將和你分享我對於 Helm 的一些思考。

本文將說明我不相信那些大肆宣傳的原因。

1

Helm 的真正價值是什麼？

到現在我仍然不清楚 Helm 的價值。它沒有提供任何特別的東西。Tiller 帶來了什麼價值（伺服器端部分）？

許多 Helm 圖表還很不完善，需要花些功夫才能把它們用在 Kubernetes 集群上，例如，缺少 RBAC、資源限制或網路策略；這意味著你無法以二進位方式安裝 Helm 圖表，忘記裡面有什麼吧。

我希望有人可以向我解釋一下

安全的多租戶生產環境

方面，而不僅僅是使用 hello world 的例子吹噓它有多酷。

Linus Torvalds 說過，"Talk is cheap. Show me the code."

2

另一個身份驗證 & 訪問控制層

有人把 Tiller 比作「巨型 sudo 伺服器」。對我來說，它只是另一個授權層，沒有訪問控制，而且需要維護額外的 TLS 證書。為什麼不利用 Kubernetes API，依賴現有的具有適當審計和 RBAC 功能的安全模型呢？

3

它只是一個被美化了的模板工具？

它就是使用 values.yaml 中的配置渲染和檢查 go-template 文件。然後，把渲染好的 Kuberentes 清單以及相應的元數據存儲在 ConfigMap 中。

這可以使用幾個簡單的命令替代：

$ # 使用 golang 或 python 腳本渲染 go-template 文件
$ kubectl apply --dry-run -f .
$ kubectl apply -f .

據我觀察，團隊常常在每個環境中都有一個 values.yaml 文件，甚或是在使用之前從 values.yaml.tmpl 渲染它。

對於 Kubernetes Secrets 來說，這是沒有意義的，因為它們通常是在庫中進行加密和版本化。你既可以使用 helm-secrets 插件來實現這一點，也可以使用 set key=value 來覆蓋它，但它還是增加了另外一層複雜性。

4

作為基礎設施生命周期管理工具

忘了它吧。它不會奏效，特別是對於核心的 Kubernetes 組件，如 kube-dns、CNI 提供程序、「集群自動定標器（cluster autoscaler）」等。這些組件有不同的生命周期，Helm 不適合這些組件。

根據我使用 Helm 的經驗，對於使用基礎 Kubernetes 資源（很容易地從頭重新創建，而且沒有複雜的發布過程）的簡單部署，它可以做得很好。

遺憾的是，Helm 不能處理更高級和頻繁的部署，包括名稱空間、RBAC、網路策略、ResourceQuota 或 PodSecurityPolicy。

我知道這可能會冒犯對 Helm 著迷的人，但這是一個可悲的事實。

5

Helm 狀態

Tiller 伺服器將信息存儲在位於 Kubernetes 內部的 ConfigMaps 中。它不需要自己的資料庫。

遺憾的是，由於 etcd 的限制，ConfigMap 的限值僅有

1MB

。

希望有人能想出個注意來擴展 ConfigMap 存儲驅動程序，在存儲之前壓縮序列化的版本，但在我看來，這仍然不能解決實際問題。

6

隨機故障和錯誤處理

這是我最擔心的事情——我不能依賴它。

Error: UPGRADE FAILED: "foo" has no deployed releases錯誤：升級失敗：「foo"沒有已部署的版本

恕我直言，這是 Helm 令人討厭的問題之一。

如果第一次發布失敗，那麼隨後的每次嘗試都會返回一個錯誤，說它無法從未知狀態升級。

下面 PR 通過添加 --forceflag 來「修復」它，但實際上是通過執行 helm delete&helm install --replace 隱藏了問題：https://github.com/kubernetes/helm/pull/3597

然而，大多數情況下，你最終會徹底清理該發布。

helm delete --purge $RELEASE_NAME

如果 ServiceAccount 缺失或 RBAC 不允許創建特定的資源，Helm 將返回以下錯誤消息：

Error: release foo failed: timed out waiting for the condition

很遺憾，Helm 並沒有提供出現這種情況的根本原因：

kubectl -n foo get events --sort-by="{.lastTimestamp}"
Error creating: pods "foo-5467744958" is forbidden: error looking up service account foo/foo: serviceaccount "foo" not found

有個別情況下，Helm 成功失敗而不做任何事情。例如，有時它不更新資源限制。

7

helm init 運行單副本 Tiller——非 HA

在默認情況下，Tiller 不是 HA 的，下面的 PR 仍處於打開狀態：

https://github.com/helm/helm/issues/2334

有一天，這可能會導致宕機……

8

Helm 3？ Operators？ 未來？

Helm 的下個版本將帶來一些值得期待的特性：

• 
  

  不分客戶端 / 伺服器端的單服務架構——無需 Tiller



• 
  

  嵌入式 Lua 腳本引擎



• 
  

  拉式 DevOps 工作流， 一個新的 Helm Controller 項目將會啟動

要了解更多信息，請查看 Helm 3 （https://github.com/helm/community/blob/master/helm-v3/000-helm-v3.md）設計提案。

我非常喜歡無 Tiller 架構的想法，但對於 Lua 腳本，我不確定，因為它會額外增加圖表的複雜性。

最近我發現 Operators 有一個大的變化，與 Helm 圖表相比，它更像是 Kubernetes 原生的。

我真希望社區能儘快解決這個問題，但與此同時，我更傾向於盡可能少地使用 Helm。

不要誤解我——我花了一些時間在 Kubernetes 之上構建了一個混合雲部署平台，以上這些只是我從中得出的個人觀點。

英文原文

https://medium.com/virtuslab/think-twice-before-using-helm-25fbb18bc822

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！

本站內容充實豐富，博大精深，小編精選每日熱門資訊，隨時更新，點擊「搶先收到最新資訊」瀏覽吧！

請您繼續閱讀更多來自 InfoQ 的精彩文章: