你覺得Helm 3無聊？其實這說明它成熟了

如果你聽說過關于Helm 3的唯一一件事就是它删除了Tiller動态配置檔案生成工具，那麼你已經知道最重要的一點：該項目經曆了一次重大的重寫，以趕上Kubernetes的發展并消除長期的安全問題。

這是項目成熟的标志，也反映在其他關鍵開發中，如更好的更新檔合并、對可用性（包括釋出管理）的重大改進，以及對Helm 2 chart的明确支援生命周期。

微軟的Helm主程式經理Bridget Kromhout表示，對于安全性和穩定性來說，這是一個很好的信号。

“Helm 3更簡單，更安全，它可能不會吸人眼球，但這些功能足以讓運維大規模系統的人高興。"

“一個項目删除大塊代碼，這是成熟的标志。”Azure Container Compute和Kubernetes 1.16釋出的首席程式經理Lachlan Evenson表示，“我們需要做的是改善安全。在Helm 2社群我們聽到的是，我們喜歡Helm，但是Helm的安全特性并不是我們在生産中想要的。”

去掉Tiller

Helm是一個古老的項目，由Deis在Kubernetes之後不久開始研發，并在第一次Kubecon上宣布。Helm 2是與谷歌的Kubernetes Deployment Manager團隊一起建構的，添加了Tiller元件和GRPC來處理Helm chart的安裝和管理，呈現chart并将它們推送到Kubernetes API伺服器。

Tiller允許團隊共享一個Kubernetes叢集，多個operator可以使用同一組版本，但是随着Kubernetes API的發展，Tiller沒有跟上，這導緻了一些人擔心授予任何可以通路Tiller的人的權限過于寬泛。

“Helm的問題很多都是關于安全性的，比如如何将現成的軟體安全地傳遞到叢集中？”Azure Compute主管Gabe Monroy解釋道，他在Deis的團隊啟動了這個項目。“Helm 3被重新設計，移除了Tiller，并将許多邏輯轉移到更現代的Kubernetes技術中，比如operator和用戶端模闆。”

移除Tiller是可能的，因為自從Helm 2在2016年釋出以來，Kubernetes增加了一些重要的功能，比如Role-Based Access Control和Custom Resource Definitions。“當時，沒有CRD，也沒有RBAC。God是唯一模式，沒有其他方法可以做到。”

既然CRD已經可用，就不再需要Tiller來維護狀态或成為通過Helm部署的釋出資訊的中心樞紐——所有這些資訊都可以作為記錄存儲在Kubernetes中。使用者身份驗證和授權現在由Kubernetes完成，Helm權限隻是Kubernetes權限，是以它們使用RBAC，叢集管理者可以選擇要使用的細粒度Helm權限。

代替Tiller的客戶機-伺服器模型，Helm變成了Kubernetes用戶端——這樣去除了複雜度層，但仍然給運維人員提供他們需要的工具。

IBM進階軟體工程師兼Helm核心維護人員Martin Hickey表示，如果你習慣了Helm 2，這将是思維方式的一個重大轉變。

Helm 3還降低了安裝和運維的複雜性

當你部署一個版本時，它并沒有存儲在叢集内的命名空間中。它被儲存在Tiller的命名空間裡。預設情況下，這就是kubesystem。這是你的系統命名空間！如果你習慣了Helm 2的工作方式，命名空間的改進可能會有些混亂，因為你必須在正确的地方尋找你的部署。

“因為Tiller是在god模式下運作的，除非你對它進行了不同的配置，否則helm-ls指令會傳回所有東西。現在它将進入你要求它進入的命名空間-是的，現在你必須建立命名空間。”

版本、配置和chart

沒有Tiller，Helm需要一種方法來跟蹤叢集中不同版本的狀态。Helm 2可以選擇使用秘密來釋放對象，現在這是預設的。

與版本一起存儲在命名空間中的版本資訊也非常不同：它既包括關于chart的特定安裝的版本執行個體，也包括存儲版本更新、復原或删除詳細資訊的ReleaseVersion秘密。

如果你需要在多個地方安裝同一個應用程式，那麼将版本資訊存儲在相關的命名空間中也可以更容易地重複名稱。對于Helm 2，如果有一個為叢集運作的Tiller執行個體，那麼版本名稱必須是唯一的。

随着Tiller的消失，Helm現在直接與Kubernetes API對話，helm init和home也被删除，因為你不需要它們來建立和存儲配置；相反，配置檔案現在使用XDG存儲。

盡管Helm基本上是重寫了來删除Tiller，Helm 2 chart仍将可以用于Helm 3（少數例外，這将意味着它們需要更新）。

“架構非常不同，更加現代化，但它仍然具有生态系統中建立的内容的所有相同優點，

QQ賬号買号

這些内容為你提供了輸入helm install kafka的良好體驗，并且你有一個增加了安全性的kafka叢集正在運作。”

圍繞CRD的變化反映了這樣一個事實：Kubernetes生态系統仍然在決定如何管理VRD，以避免類似DLL地獄的情況。“一個應用程式可以擁有一個CRD，CRD也可以由許多應用程式擁有，我們試圖用chart來管理CRD。我們已經對它進行了簡化和重新設計，隻建立CRD；是以不再進行修改或删除。現在将自動安裝CRDS，但是如果它們已經存在，不再安裝，并且有一個指令跳過安裝。這符合越來越普遍的DevOps模式，即用一個chart安裝CRD，然後用自己的chart安裝應用程式。”

如果希望chart既可以用于Helm 2，也可以用于Helm 3，請確定它們建立了命名空間并同時使用crd install鈎子和crds/目錄；Helm 3将忽略該鈎子，并發出警告。

但是如果你已經準備好了用Helm 3，你可以利用一些新的chart特性，但應該将helm3 chart标記為使用Helm version 2 API。

需求和依賴關系會移動到chart.yaml檔案中，是以需要為Helm 2和3分别指定它們。chart現在還可以使用JSON模式來驗證install、upgrade、template和lint指令，以便更清楚地知道需要設定哪些值。

當你使用Helm更新版本時，它現在執行一個三向合并，其中包括live cluster狀态以及使用最新的和建議的chart清單。

更簡單，更安全

Helm 3重新架構的另一個結果是Go-SDK也進行了重組。CLI是圍繞SDK的一個包裝器，使其易于使用，但是如果你想建立更複雜的部署模式，則需要直接使用SDK并在Helm 2中使用，這很難做到。“現在它已經很好地被解壓出來了，而且包更好地封裝在遠離CLI部分的地方。”如果你想讓Helm成為管道的一部分（在這個管道中你需要使用Helm所做的一部分并在其間插入自己的步驟），那麼可以直接調用Go SDK中的包來完成這項工作。實際上，從Helm 2遷移到3的插件就是這樣工作的。

強調Helm引擎和社群chart内容的成熟度，是該項目從雲計算基礎孵化狀态中畢業的一步，也是通過其先決條件的第三方安全稽核的一步。

與Helm安全審計一起，Snyk還對public Helm repo中的chart進行了安全審計，查找這些圖表引用的鏡像中的漏洞。

Helm這樣被廣泛使用的技術（每月下載下傳量超過100萬次，是CNCF第三大被采用的技術）仍在孵化中，這是令人驚訝的。它曾經是一個頂級的Kubernetes項目，直到2018年Kubernetes自己“搬到”CNCF後才成為一個獨立項目。随着安全審計的完成，Helm很可能在2020年初畢業。

“圍繞Helm的社群規模龐大，種類繁多，并繼續以令人難以置信的速度增長。能夠用一個指令安裝複雜軟體，是Kubernetes和CNCF生态系統所追求的。Helm支援helm安裝模式，而生态系統的其他部分仍在努力實作這種模式。”

能夠在不影響使用者的情況下進行重大的内部更改，使項目與目前關注的問題保持相關性，這是一項令人印象深刻的成就。盡管在雲原生世界中有各種各樣的打包和安裝工具，Helm仍然能夠很好地保持相關性。

“經得起時間考驗的平台有能力随着技術基礎的變化而發展。Kubernetes正在展示以這種方式進化的能力，Helm也是一樣的。”