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

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