Helm:三思而後用
Helm是Kubernetes的包管理器。它可以大幅簡化釋出過程,但有時候也會帶來問題。近日,Helm已經正式提升為頂級的CNCF專案,並且在社群得到了廣泛的應用。這說明Helm確實是個不錯的專案了,但我將和你分享我對於Helm的一些思考。
本文將說明我不相信那些大肆宣傳的原因。
Helm的真正價值是什麼?
到現在我仍然不清楚Helm的價值。它沒有提供任何特別的東西。Tiller帶來了什麼價值(伺服器端部分)?
許多Helm圖表還很不完善,需要花些功夫才能把它們用在Kubernetes叢集上,例如,缺少RBAC、資源限制或網路策略;這意味著你無法以二進位制方式安裝Helm圖表,忘記裡面有什麼吧。
我希望有人可以向我解釋一下安全的多租戶生產環境 方面,而不僅僅是使用hello world的例子吹噓它有多酷。
Linus Torvalds說過,"Talk is cheap. Show me the code."
另一個身份驗證&訪問控制層
有人把Tiller比作“巨型sudo伺服器”。對我來說,它只是另一個授權層,沒有訪問控制,而且需要維護額外的TLS證書。為什麼不利用Kubernetes API,依賴現有的具有適當審計和RBAC功能的安全模型呢?
它只是一個被美化了的模板工具?
它就是使用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來說,這是沒有意義的,因為它們通常是在庫中進行加密和版本化。你既可以使用ofollow,noindex" target="_blank">helm-secrets 外掛來實現這一點,也可以使用set key=value來覆蓋它,但它還是增加了另外一層複雜性。
Helm作為基礎設施生命週期管理工具
忘了它吧。它不會奏效,特別是對於核心的Kubernetes元件,如kube-dns、CNI提供程式、“叢集自動定標器(cluster autoscaler)”等。這些元件有不同的生命週期,Helm不適合這些元件。
根據我使用Helm的經驗,對於使用基礎Kubernetes資源(很容易地從頭重新建立,而且沒有複雜的釋出過程)的簡單部署,它可以做得很好。
遺憾的是,Helm不能處理更高階和頻繁的部署,包括名稱空間、RBAC、網路策略、ResourceQuota或PodSecurityPolicy。
我知道這可能會冒犯對Helm著迷的人,但這是一個可悲的事實。
Helm狀態
Tiller伺服器將資訊儲存在位於Kubernetes內部的ConfigMaps中。它不需要自己的資料庫。
遺憾的是,由於etcd/blob/master/Documentation/dev-guide/limit.md" rel="nofollow,noindex" target="_blank">etcd的限制 ,ConfigMap的限值僅有1MB 。
希望有人能想出個注意來擴充套件ConfigMap儲存驅動程式,在儲存之前壓縮序列化的版本,但在我看來,這仍然不能解決實際問題。
隨機故障和錯誤處理
這是我最擔心的事情——我不能依賴它。
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成功失敗而不做任何事情。例如,有時它不更新資源限制。
helm init執行單副本Tiller——非HA
在預設情況下,Tiller不是HA的,下面的PR仍處於開啟狀態:https://github.com/helm/helm/issues/2334
有一天,這可能會導致宕機……
Helm 3? Operators? 未來?
Helm的下個版本將帶來一些值得期待的特性:
我非常喜歡無Tiller架構的想法,但對於Lua指令碼,我不確定,因為它會額外增加圖表的複雜性。
最近我發現Operators 有一個大的變化,與Helm圖表相比,它更像是Kubernetes原生的。
我真希望社群能儘快解決這個問題,但與此同時,我更傾向於儘可能少地使用Helm。
不要誤解我——我花了一些時間在Kubernetes之上構建了一個混合雲部署平臺,以上這些只是我從中得出的個人觀點。
檢視英文原文:slab/think-twice-before-using-helm-25fbb18bc822" rel="nofollow,noindex" target="_blank">Think twice before using Helm
感謝張嬋對本文的審校。