在最近結束的阿姆斯特丹Helm峯會上，Helm項目是焦全場矚目的焦點Helm已經是Kubernetes社區事實上的包管理器，並且，作爲頂級項目，即將進入雲原生基金會（Cloud Native Compute Foundation，簡稱CNCF）。
Helm是一個應用程序包管理器，在Kubernetes上運行，並通過Helm Charts描述應用程序的結構，使安裝和管理包及其依賴項變得非常方便。Helm類似於操作系統包管理器yum、apt和homebrew等等。
隨着微服務的出現以及需要獨立地對這些服務進行擴展和管理，Helm通過Helm Charts的使用，提供了一種實現此目的的方法。
InfoQ採訪了阿姆斯特丹Helm峯會的組織者Matt Butcher，探討了Helm的成長之路及其路線圖。Matt Butcher談到了Helm的歷史、其它的計如何受到其他包管理器的影響、其它何幫助Kubernetes社區、其它的大的成長以及一些正在解決的安全挑戰。
InfoQ：您是否先能夠簡要講講最近的Helm峯會的“旅行報告”以及Helm的簡史？您是否能對Helm是如何開始的提供一些見背景知識及一些可關的內幕故事？
Matt Butcher：在Deis，我帶曾領一個團隊去建首個基於Kubernetes的PaaS產品，它被稱爲Deis Workflow。至至少來講很個多微服務的應用程序。很難安裝在Deis召開爲期2天的全公司大會的時候，我們有一個編程馬拉松團隊建設活動。在編程馬拉松中獲勝的團隊將得到一張75美元的亞馬遜禮品卡。我和Jack Francis及Rimas Mocevicius組了個隊，我們決定挑戰一下在Kubernetes中安裝應用程序的難題。在那個爲期2天的編程馬拉松中，我們構建了一個工具，我們稱它爲“K8S Place”（讀作“Kate’s Place”），那是一個Kubernetes的包管理系統。我們贏了這場編程馬拉松。
在全公司大會結束的第二天，首席執行官和首席技術官給我打了電話。他們一一直在誇獎我們並想知道Jack、Rimas和我是否認爲能夠把這個K8S Place做成真正的工具。我說，我覺得可以。但是，我們都同認爲8S Place這個名字對於一個項目來說有點太可不正式。因此，Jack和我通過電話通讀了航海術語表，爲這個項目尋找一個與Kubernetes主題相符的更好的名字。於是，Helm就這麼誕生了。
幾個月後，我們在首屆KubeCon大會上向公衆推出了Helm。又過了幾個月，Helm成爲正式的Kubernetes子項目。
首關於次Helm峯會是Helm得到了很多關注，大大超過了我們的預期。但是，當參加KubeCon大會時，我我們陷入了一種窘境，那就是隻能提供相當標準的深入分享但是，由於Helm的生態系統太大了，因此，KubeCon的組織者無法給Helm安排太多的討論。於是，Deis的社區經理Karen Chu（後來去了微軟的Azure）提出了召開正式Helm峯會的想法。首次峯會是在俄勒岡州波特蘭市舉行的，是單個主題的會議。會議開得不錯。我們把會場都坐滿了，我見了很多DevOps、開發人員和系統管理員。Kubernetes項目的負責人Brian Grant也來了。後來，他建議Helm可能不再適合做Kubernetes的子項目。他支持Helm直接進入CNCF，並一路幫助我們。
首個歐洲Helm峯會是在阿姆斯特丹召開的。我最初的目標是120個人，結果來了130個人。我們最初想在意大利米蘭召開會議。但是，我們找不到一個理想的會場。微軟阿姆斯特丹內部的員工主張在他們那裏開會，因此，我們就換去阿姆斯特丹開會了。
Helm阿姆斯特丹峯會是首個由CNCF運作的Helm活動。那次會議非常棒。他們帶來了深厚的專業知識，與他們共事也很愉快。我從來沒有參加過組織得這麼好的會議。
對於這個峯會，我們從Helm波特蘭峯會的單軌風格換到了雙軌會議。這使我們可以接受更多的演講者，並且還可以隨着常規討論同步提供工作坊內容。討論的質量很高，就我所知，我們得到了一致好評。我認爲，獲得好評的主要因素是會議的規模。我覺得，我幾乎和每一位參會人員都握手問好。而有12000人蔘加的KubeCon是很趣和，但是太急促了像這個規模比較小的大會可以讓人們建立人脈關係，並提供充分的機會來結識志趣相投的人。
對我來說，Helm峯會的高光時刻是遇到了Yusuke（在Kubernetes世領域，以他在itHub的句名號是mumoshu”聞。我和Yusuke在網上合作了多年，他對很多與Helm相關的項目及Brigade（我發起的另一個CNCF項目）貢獻良多。但是，我們從來沒有機會見面。我從科羅拉多飛到那裏，而他從東京飛去那裏。這是一個奇妙的世界，我們生活在其中，可以合作多年而從來沒有真正見過面，而我們第一次見面是在對我們來說都陌生的大陸上。
InfoQ：由於Helm經常被定位於Kubernetes的包管理器，與Homebrew/apt/yum類似，與開發人員和架構師相比，系統管理員是否更適合用Helm？
Butcher：Jack、Rimas和我曾深受Apt和Homebrew的啓發。Adam Reese和Michelle Noorali（在Helm作爲Deis項目的第一個官正式工作加入Helm項目）都深受Ruby生態系統的影響。我們都相信，我們正在把打包的隱喻擴展到一個全新的領域：雲原生（分佈式）應用程序。
正如我們所看到的（並且我認爲，我可以輕鬆自在地爲替們說話），Helm的首要目標一直是讓“從零到Kubernetes”故事變得輕鬆。無論是開發人員、經驗豐富的DevOps工程師，還是剛剛入門的學生，我們的目標是讓大家在兩分鐘內就可以在Kubernetes上安裝應用程序。
當然，自我們設定這個目標之日起，事情已經發生了很大的變化。Kubernetes受歡迎的程度呈爆炸式增長。現在，常產K環境的8S集羣。非常常見在一這樣的轉折點，問提出個問題是件好事：誰是Helm真正的受衆？
我們認爲，從事運維的人將是Kubernetes最直接的受益者。由Bitnami（如今是VM Ware）的的工程師設計的Helm Hub是一個考專爲ubernetes運維的設計門戶網站。
但是，我們一直在努力工作以使Helm Charts易於開發人員創使用我的團隊創建了一個稱爲“Draft”的項目，那該項目專門計用爲助開發人員實現代碼到圖Chart轉換，而無需先學習Kubernetes清 manifest在這裏（在Helm和我們其他的項目中），我們的設計理念是：給人們提供工具，讓他們能完成現在最重要的工作，然後，給他們提供方法，以“向後學習”基礎技術。Ruby On Rails在Ruby世界中做得非常好，我們一直把它視爲我們工作的靈感來源。
InfoQ：Helm Charts否取克服安裝Kubernetes應用程序的所需的AML文件的複雜性？其他的一些批評，特別是關於Kubernetes的複雜性，在Helm中是如何處理的？
Butcher：我們用圖Chart式的主要目的是讓Kubernetes的新手不再必須爲了在Kubernetes上安裝什東西要看Kubernetes YAML清 manifest但是，由隨着這些用戶對於使用Kubernetes做更多的事情表現出越來越濃厚的興趣Helm會變成一個教入門的學工具。再者，借鑑之前的回答，Helm旨在幫助人們“向後學習”進以深入ubernetes。安裝一個圖Chart，後去看看創建了什麼（畢竟，Helm會告訴我們這些）。然後，改變一些東西。試試這些改變的東西。看看更多的圖Chart看看它們是如何工作的。很快，積極的Helm用戶變成有豐富Kubernetes知識的用戶。並且，在整個學習過程中，這些人能夠成功地部署應用程序了！
我們爲Helm 3感到自豪的一件事情是，圖Chart然相對簡單。我們有曾經糾結過是否要加大量不同的模板語言、更多的鉤子，以及各種附加的花哨功能。但是，當我們在聽取用戶的意見時，我們聽到的是：
(a)對於學習來說，越簡單越好
(b)我們提供的工具大致滿足了95%的用戶用例需要
©當Helm不夠用時，相當多的附加工具已經被創建以填補不足
InfoQ：Helm是否與微服務的持續集成或交付（CI/CD）相關？如果相關，Helm在其中扮演什麼角色？
Butcher：我不確定把CI和微服務組合在一起是否合適，但我會試試。
微服務架構已經變成一種新東西：它已經變成一種真正編寫和操運維布式應用程序的方法。但是，爲了做好這個，微服務確實需要Kubernetes提供的編排層。否則，把所有的部分連接在一起就太複雜了。
Helm解決了雲原生/分佈式應用程序領域的一部分：問題它使Kubernetes部分變得更容易了。但是，我要說，我們在一些關鍵方面存在不足：
Helm只解決了方整個領域中ubernetes的分。的問題但是，現代雲產品包括託管服務、託管工具（如數據庫服務）、虛擬機、網絡存儲，所有這些都在Kubernetes之外。Helm對這些無能爲力。Helm不管理容器圖鏡像它假設那些是由外部管理的，它僅僅管理Kubernetes清 manifest
我們考慮過把這兩個都加到Helm上，但是，我們意識到，這個會毀了我們喜愛Helm的一個關鍵因素：簡單性。
遵循UNIX“做好一件事”的思想，我們創建了一個新工具，以處理大型雲原生空領域的問題我們創建了一個開放規範，稱爲雲原生應用程序束bundleCloud Native Application Bundles，簡稱CNAB），並把它捐獻給了Linux基金會的JDF，然後，創建了一個引參考現和一個可選的聲明式構建器。CNAB配合Helm，還有Terraform、Ansible，以及幾乎所有的部署管理工具一起使用，以實現雲原生應用程序真正豐富的部署。
CI也是個有趣的故事情我們經常把Helm Charts部署爲作Ggitops風格道的一部分。我們構建的其他工具也有類似的需求。但是，當我們研究CI和CD時，我們注意到一些未知領域。Kubernetes提供了持續操作的基本層：作Job短暫的pod運行時，而Deployments對長時間運行的網關是完美的選方案但是，我們在2017年來看這個領域時，沒有人在利用Kubernetes的這個能力。
因此，我們利用從Helm獲得的知識，創建了Brigade。但是，Brigade不僅僅是個CI系統。它更具靈活性。受到UNXIX本允許用戶把shell命令鏈在一起並把數據從一個管道傳到另一個管道方法的啓發，我們創建了用於編寫腳本（用JavaScript編寫）的通用框架，可以把Docker容器鏈接在一起，從而把信息從一個容器傳到另一個容器，以形成處理管道。
Brigade也是一個CNCF項目，在此之上提供一個事件驅動接口。因此，我們可以編寫Brigade腳本，以響應GitHub拉取請求、雲事件、Kubernetes API事件、Kafka 公共/子消息等等，前做什麼都可以
在阿姆斯特丹的Helm峯會上，Yusuke（mumoshu）做了一個演講，展示了他如何選擇Brigade併爲Helm Charts構建了一個複雜的CI管道，然後將測試過的圖Chart遞給一個CD系統，該系統立即把這些圖Chart署到生產中。 看到有人從我的想法中獲得一點點靈感並付諸實踐，創造了一些我的團隊開始構建Brigade時我所能想象到的更加優美、更強大的東西，那真是個令人愉悅的時刻。
InfoQ：請問，Helm 3中有什麼新功能？Helm的Tiller集羣側組件的一些安全問題如何解決？
Butcher：首先，澄清一下，“Helm 2不安全的謠言被極大地誇大了”。主要的抱怨是，Kubernetes不默認是默租戶安全的，這是事實。必須在Helm中打開安全選項。一有些非常吵嘈雜個播謠言，說什麼在Helm中有一些深層次和固有的安全漏洞，而實際上，解決方案就是“打開mTLS”。（Helm本身只有兩個CVE，都不是至關重要的。）
Helm 3完全移除了Tiller。當我們把Tiller加到Helm 2的時候，我們從未感到激興奮但當時，Kubernetes似乎準備全部採用gPRC，而我們曾設想過一種更綜合的體驗。與但事實上Kubernetes堅後來持使用YAML和REST。因此，我們盡職盡責地完成了Helm 2週期，而沒有做任何有破壞性的改變。然後，我們在Helm 3分支中做的第一件事就是把Tiller移除，並重構代碼。現在，Helm 3 使用具有原子版本控制的集羣內資源來存儲發佈，但不再要求在集羣內運行任何代碼。
我們儘量自己最大的努力以保持對emVer2的忠穩定性不破壞Helm 2.0與現在版本之間的兼容性。但是，Helm 3是我們修復很多問題的機會。比如，CRD引入Helm 2生命週期一年多了。因此，我們無法用可能破壞現有客戶或圖表的方式來增加對CRD的支持。但是，有了Helm 3，我們終於能夠編寫出一個CRD的合理實現。
儘管我們已經基本上重寫了Helm的整個發clockworks置，其中很酷的一件事是，Helm的日常用戶將完全不需要改變什麼。一些命令行標誌變了。我們引入了一個新的圖Chart式（Chart v2），但是，幾乎一切就像往常一樣“正常工作”。關於已建立Helm的安裝，我們甚至有了一個遷移工具，以簡化轉換。
InfoQ：您是否能談談Helm社區的發展？在Helm中，您是否還有什麼要強調的，可以讓開發人員和架構師避免一些痛點？
Butcher：Helm的生態系統已經足夠大了，我可以不再關注它了。在我的生命中，最讓我石化的瞬間是有個人看到我身上有Kubernetes徽標，就把我推薦給他們公司，而這家公司的收入來自Helm。他不知道我是誰，我也沒有告訴他。我只是安靜地聽他講，問了幾個問題，然後該幹嘛就幹嘛去了。但是，對我來說，這是一個非常重要的時刻。我從來沒有真正想過這個事實，我的團隊構建的工具真的是一個有20多人的公司的生計來源。
我們曾經在GitHub上追蹤 Helm生態系統中的所有工具。但是，在現在個文文檔全代不能表這繞着該項目形成的更大的生態系統了。我無法告訴你，知繞着我們的那個黑客馬拉松小項目已經構建了這麼多項目是，我們有麼的得幸。開源……有那麼幾天，這個想法拂過了我的腦海。想到世界上那麼多開發人員花了數以千計的小時來構建工具，這些工具解決了他們的麻煩，然後，他們把這些工具提供給其他人使用和擴展。
在代碼方面，我完全被社區的參與震撼了。來自700多家公司的數千位貢獻者已經幫助我們構建了Helm、創建圖Chart管理核心Helm工具和網站。其中有很多人還爲更廣泛的生態系統的其他項目做出了貢獻，其中包括Helmfile、Helm Hub和Monocular。
我可以說，我爲Helm感到自豪。但是，“自豪”並不是一個恰當的詞。這意味着我把它提升到了我想要做的東西。相反，我被Helm震驚了。參與的人、代碼、生態系統，所有這些遠遠超過了Jack、Rimas和我在我們首次推出我們小小的K8S Place演示時所能想象的。兩年前，當微軟收購Deis的時候，我被問到，我對Helm的希望是什麼。當時，我說：“我希望Helm是個爲期10年的項目”，意思是，我希望它能夠在這個快節奏的軟件世界中到達成熟的階段。並且，我仍然希望這是真的。但是，如今，我對Helm的真正希望是，圍繞着它的社區願景將繼續超越我淺薄的想象。
總而言之，Helm已經成爲Kubernetes事實上的包管理器，並且，隨着其解決了基礎設施平臺上核心應用程序開發的痛點，它經歷了穩定的成長。
更多細節請參看D它的文檔其中包括入門指南。
原文鏈接：Helm as a Package Manager for Kubernetes: Q&A with Helm Founder Matt Butcher