在最近结束的阿姆斯特丹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

创作场景

专访 Kubernetes 包管理器 Helm 创始人：希望 Helm 是个为期 10 年的项目