作者:Matt Fisher
2015年10月15日,现在被称为Helm项目诞生了。仅仅一年之后,当Helm 2快来到时,Helm社区加入了Kubernetes组织。2018年6月,Helm社区作为孵化项目加入了CNCF。时间快进到今天,Helm 3即将发布第一个alpha版本。
在接下来四周的七篇博客文章中,我将提供一些关于Helm开始的历史,说明我们是如何来到今天,展示Helm 3第一个alpha发行版中的一些新特性,并解释我们将如何从这里继续前进。
按顺序,我将讨论:
Helm的历史
让我们开始吧。Helm 3预览:探索我们的未来博客系列7部中的第1部是关于Helm如何创建和发展的历史。
Helm的出生
Helm 1最初是Deis创建的一个开源项目。我们是一家小型初创公司,在2017年春天被微软收购。我们的另一个开源项目 — 也称为Deis — 有一个名为deisctl的工具,主要用于在Fleet机群上安装和操作Deis平台。Fleet是当时最早的“容器编配器”平台之一。
https://blogs.microsoft.com/blog/2017/04/10/microsoft-acquire-deis-help-companies-innovate-containers/
https://github.com/coreos/fleet
2015年年中,我们决定换挡,Deis的基础(现在重新命名为“Deis工作流”)从Fleet转移到Kubernetes。我们首先要重写的是安装工具deisctl。我们使用这个工具在一个机群上安装和管理Deis工作流。
参照Homebrew、apt和yum等包管理器,Helm 1的重点是让用户更容易地在Kubernetes上打包和安装应用程序。2015年,我们在旧金山的KubeCon大会上正式宣布Helm。
我们第一次尝试Helm是成功的,但也有一定的局限性。它使用了一组Kubernetes清单,将生成的结果加载到Kubernetes中。
例如,要替换YAML文件中的字段,可以在清单中添加以下内容:
#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml
模板语言的存在让你非常高兴,是吧?
由于许多原因,这个早期的Kubernetes安装程序需要一个硬编码的清单文件列表,并且只执行一小段固定的事件序列。Deis工作流研发团队在围绕其重新开发产品时经历了一段艰难的时期,这已经够痛苦的了,但是一个想法的种子就在那里发芽。我们的第一次尝试是一个非常成功的学习机会:我们了解到,我们热衷于为用户构建实用的解决方案,为他们解决实际的日常问题。
从过去的错误中吸取教训,我们开始设计Helm 2。
设计Helm 2
随着2015年接近尾声,来自谷歌的一个团队向Helm团队伸出了援手。他们也一直在为Kubernetes开发类似的工具。Kubernetes的部署管理器(Deployment Manager)是他们用于谷歌云平台的现有工具的一个移植。他们问道,我们是否有兴趣花几天时间来讨论相似点和不同点?
2016年1月,Helm和部署管理器团队在西雅图坐下来分享一些想法。我们提出了一个大胆的计划:合并项目来创建Helm 2。随着Deis和谷歌的加入,SkippBox加入了开发团队,我们开始了Helm 2的工作。
https://github.com/skippbox
我们的目标是保持Helm的易用性,但添加了以下内容:
为了实现这些目标,我们向Helm生态系统添加了第二个组件。这个集群内组件被称为Tiller,它负责安装和管理Chart。
Helm 2自2016年发布以来,Kubernetes增加了几个主要功能。增加了基于角色的访问控制(Role-Based Access Control,RBAC),并最终取代了基于属性的访问控制(Attribute-Based Access Control ,ABAC)。引入了许多新的资源类型(当时Deployment还处于beta测试阶段)。发明了自定义资源定义(Custom Resource Definition,当时称为第三方资源,Third Party Resource或TPR)。最重要的是,出现了一组最佳实践。
在所有这些变化中,Helm继续满足Kubernetes用户的需求。经过3年的时间和许多新特性的添加,对代码库进行一些主要的更改是一个好主意,这样Helm就可以继续满足这个不断发展的生态系统的需求。
这把我们带到了Helm 3 - 我们的下一篇博客文章讨论Tiller的命运。不要错过Helm 3预览:探索我们的未来博客系列共7部文章。