在最近於聖地亞哥舉行的 KubeCon+CloudNativeCon 2019 大會上，有超過 12000 名與會者出席，Helm 尤其是 Helm 3.0.0 的發佈成爲了全場焦點。
Helm 是 Kubernetes 的一個包管理器，類似於 yum、apt、Homebrew 等操作系統的包管理器，它使得安裝和管理包及包的依賴關係變得更加容易。在與聯合創始人 Matt Butcher 的訪談中，我們已經瞭解到 Helm 的歷史源於第一次的 KubeCon 。因此，它遺留了一些技術債，其中就包括備受爭議的服務端組件 tiller 。
InfoQ 就 Helm 3.0.0 的發佈採訪了微軟軟件工程師、Helm 和 Draft 的維護者之一 Matt Fisher。
Fisher 談到了 Helm3.0.0 的特性，這是一個主版本，訪談中包括了它的一些技術債的成因以及是如何克服它們的，其中這些技術債主要是與 tiller 相關的。他還談到了 Helm 對向後兼容的承諾，這對項目來說一直都是很重要的。在這個訪談中，他還概述了 Helm 2 和 Helm 3 之間的一些關鍵變化。
InfoQ：Helm 3.0.0 是一個主版本，對吧？在我們討論 tiller 之前，您能否先高度概述下該新版本中的功能呢？
Matt Fisher：最明顯的變化是去除了 tiller。
Helm 3 採用了一種三向合併補丁（ three-way merge patch）的策略。在生成補丁時，Helm 會考慮先前版本的狀態、“實時”狀態和建議的狀態。在 Helm 2 中，它使用的是雙向合併補丁（two-way merge patch）策略。
發佈版本的發佈分類賬現在存儲在與發佈版本本身相同的命名空間中。這意味着 helm install wordpress stable/wordpress 可以按命名空間進行管理。另一個變化是引入了 JSON 模式，可以將其應用於chart值。這可以確保用戶提供的值是遵循chart維護者所定製的模式的，從而允許用戶在發佈過程的早期捕獲錯誤，並確保能按照chart維護者的預期來提供值。
一些功能已經被棄用或重構了，這使得它們與 Helm 2 不兼容。helm serve 是在 Helm 2 時首次引入的一個非常有用的工具，但是現在使用諸如 chartmuseum 之類的其他工具已經是非常成功的項目了，所以 helm serve 被從項目中移除了。
還引入了一些新的實驗性功能，其中包括 對OCI 支持。
此外，這個版本還提供了其他更多可用的功能。文檔中的 FAQ 對這些變化的內容和原因有更詳細地介紹。
InfoQ：現在，我們來談談 tiller 。您能否簡單地談一下它是什麼，爲什麼必須擺脫它，以及是如何擺脫它的呢？
Fisher：在此先介紹一下背景，這個很重要。
Helm 的第一個版本（又名 Helm Classic）是在 2015 年 11 月的首次 KubeCon 上推出的。Kubernetes 1.1.1 於當月初發布，而 1.0.0 在 2015 年 7 月發佈，兩次發佈版本僅隔了4個月。
那時，Kubernetes 還沒有 ConfigMap 的概念。 ReplicationControllers 被大肆宣傳（還記得嗎？）。Kubernetes API 的變化非常快。
在構建 Helm 2 時，我們需要一個對 Kubernetes API 的抽象層，這樣我們自己能夠留出一定空間來保證向後兼容。
Tiller 就是作爲該抽象層而創建的。它爲我們提供了一個可以控制輸入（通過 gRPC）、輸出（也是通過 gRPC）的層，併爲用戶提供了一些向後兼容的保證。
Helm 從 2.0.0 開始就一直致力於向後兼容，我們對此感到非常自豪。
隨着時間的推移，Kubernetes 的 API 層變得更加穩定。Helm 3 爲我們提供了機會去重構那些四年前引入的保護層，tiller 就是其中之一。
InfoQ：在採用容器方面，容器的安全性是最重要、最不重要還是處於中間狀態呢。開發人員和架構師還應該注意哪些與 Helm 3 相關的安全問題呢？
Fisher：在 Helm 3 發佈的前幾周，CNCF 資助了 Cure53 來對 Helm 3 進行安全審計。Cure53 已經對其他 CNCF 項目進行過審計了，其中包括 Prometheus 、Envoy、Jaeger、Notary 等項目。
整個報告都值得一讀，因爲任何摘要都不能準確地描述它。作爲其摘要的一部分，Cure53 給出了一個結論，內容如下：
根據這個由 CNCF 資助的項目得出的結論，Cure53 只能說明 Helm 項目給人的印象是非常成熟的。
這個結論是由許多不同的因素決定的，從本質上講，這意味着可以推薦 Helm 用於公共部署，特別是當需要根據開發團隊指定的建議進行適當配置和保護時。
安全審計是 CNCF 項目的優勢之一，我們對它們以及 Cure53 所做的分析表示感謝。這一分析爲我們提供了一些可以嘗試改進的具體領域，並使我們對我們所擁有的充滿了信心。
InfoQ：儘管有像 helm2to3 這樣的工具，但還是有一些破壞性的變化會阻止從 Helm 2 遷移到 Helm 3，對嗎？您能否總結一下這些變化，以及如何消除遷移過程中的困難？另外，您是否推薦同時使用 Helm 2 和Helm 3 的混合模式開發呢？
Fisher：Helm 3 是一個主版本。多年來我們一直對 Helm 2 的每個小版本和補丁版本都保持向後兼容，我們利用這個機會重寫了 Helm 的大部分內容，並且出現了一些向後兼容方面的缺陷。這些變化大多與 Kubernetes 中的存儲後端有關，或者與我們如何處理某些 CLI 標誌有關。大部分的工作都是圍繞着將 Tiller 從架構中移除後 Helm 3 會是怎樣的來展開的。
完成此操作後，我們需要確保可以順利地向前遷移，這就引入了 helm-2to3 插件。
我們考慮的一個主要設計目標是如何避免對chart進行任何破壞性的變更。我們希望可以確保已經建立了chart的社區不必再維護同一chart的兩個不同版本：一個用於 Helm 2，另一個用於Helm 3。
我們從社區成員那裏瞭解到，他們的集羣採用了絞殺者模式（strangler pattern ），使用 Helm 2 維護的版本需要繼續使用 Helm 2，但新安裝的可以使用 Helm 3。
不過，我們強烈反對用戶嘗試同時使用 Helm 2 和 Helm 3 來管理同一版本。這行不通。後端產生了一些重大的變化，這是 helm-2to3 遷移工具可以幫助他們進行遷移的地方之一。
InfoQ：您能簡單概括下 Helm 所處的生態系統嗎？關於 Helm 的工具，您推薦給開發人員和架構師的首選工具是什麼？主要差距在哪裏？
Fisher：Helm是一個包管理器，與 apt、yum、homebrew 等處於同一領域。
包管理器允許瞭解如何在某平臺上運行應用程序的人（例如，debian 上的 postgresql ）以一種其他人不需要學習就可以運行該應用程序的方式將其打包。
這就是爲什麼我可以定期使用 apt install ，而不需要了解在系統上運行這些應用程序的業務邏輯的原因。
包管理器使我們可以劃分專業知識並使之自動化。
在工具方面，使用 chartmuseum 或 Harbor 來託管自己的chart存儲庫是不會出錯的。chart-releaser 是chart存儲庫 API的另一種形式，它依賴於自動化，會使用 Github Releases 和 Github Pages 來託管chart包。
用於 Visual Studio Code的 Kubernetes 擴展有一些很好的可視化工具，可用於與 Kubernetes集羣進行交互。我發現自己在執行簡單的 Kubernetes 操作（比如 kubectl edit ）時會更高頻率地使用它，或者當我嘗試根據集羣中當前安裝的內容來組裝新的 Helm chart時也會使用它。
InfoQ：最後，除了 Helm 3 之外，還有什麼路線圖嗎？對於那些沒有使用過 Helm 的人或者那些想爲 Helm 社區做出貢獻的人，還有其他的建議嗎？
Fisher：現在，我們正在做收尾工作，並在瞭解社區的情況。我們正在努力提升穩定性並強化現有的功能集。將實驗性功能（如 OCI 註冊中心集成）推進到通用階段，並從使用 Go 客戶端庫的用戶那裏收集反饋。當然，安全修復和補丁發佈也會根據需要來進行安排。
對於那些想做出貢獻的人來說，在 #helm-users Kubernetes Slack 頻道中與其他社區成員聊天始終是一個不錯的開始。如果你遇到了問題，這也是一個尋求幫助的好地方。社區成員會與他人分享他們的故事，或者幫助他人解決他們以前遇到的某些問題，對此我都會很感動。
核心維護人員也在尋找那些將 Helm（ CLI 或Go SDK）集成到他們自己項目中的社區成員的反饋。#helm-dev Kubernetes Slack 頻道對於聯繫核心維護人員以瞭解高級主題非常有用。
Helm 3.0.0 引入了一些新功能並刪除了集羣側組件 tiller，想要了解更多關於 Helm 3.0.0 版本的詳細細節請訪問 helm.sh。更多關於 Helm 的詳細文檔可以在文檔中找到。會議上還舉行了許多關於 Helm 的議題，其中包括 Helm 3 Deep Dive。
原文鏈接：
Q&A with Matt Fisher of Microsoft about Helm 3.0.0 release for Kubernetes