1.1 Helm的发展历程
2015年10月15日，Helm诞生了。2016年，Helm加入Kubernetes社区。Helm 1（第1版Helm）是由一家名为Deis的创业公司开发的，这家公司在2017年被微软收购。Deis当时还开发了一个名为Fleet的容器托管平台，即现在我们熟悉的SaaS平台的前身，经历或了解过容器编排框架之争的读者可能听说过Fleet，它是第一个容器调度编排框架。
2015年年中，Deis的研发方向由Fleet转向Kubernetes，虽然当时Docker Swarm调度系统的发展如日中天，但后来事实证明，Deis这一步押宝可谓十分精准。
选择Kubernetes后，Deis做的第一件事就是重写应用安装工具。Deis有一个命令行工具deisctl，通过它可以将应用提交到Fleet平台。所以Deis决定重写deisctl，以便向Kubernetes平台提交应用模板。
受Homebrew、apt、yum等包管理器的启发，Deis研发Helm 1的初衷是方便用户将应用打包和安装到Kubernetes集群。后来，在2015年的KubeCon会议上，Deis发布了Helm 1。
不过Helm 1的功能并不完善，在实际应用中有相当大的局限性：它需要提前编写许多Kubernetes编排模板，然后使用类似脚本语言的方式进行渲染，最后把它们提交到Kubernetes集群中。比如想要提交一个简单的模板，就需要执行如下操作：
#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny|my/pod.yaml
这个过程看起来和直接使用sed命令操作剪切文本差不多，非常麻烦，和现在使用Helm的方式完全不一样。
由于许多历史原因，早期版本的Helm需要一套硬编码的编排文件列表，而且只能实现有限的几项功能。Helm 1使用起来非常烦琐，不过它作为首款编排模板工作引擎的尝试还是非常成功的，至少它让Deis意识到，这种应用包管理器能够很好地解决用户正面临的应用编排管理问题。
就这样，Deis从过去的错误中吸取教训，开始设计Helm 2。
2015年年末，Google的一个团队联系到Helm的研发团队，表示他们也在研发一款类似功能的工具，并且Google内部已经有了一套应用安装工具。于是，Deis与Google便一起商讨各自工具功能的异同点。
2016年1月，两个团队达成一致意见，将两家的项目合并，创建了名为Helm 2的新项目。
Helm 2的研发目标是在产品具有较强易用性的基础上，增加如下特性：
·定制化Chart模板；
·构建集群内的管理方式；
·构建可以存储Chart的仓库；
·构建稳定可签名的包格式；
·实现强版本控制以及向后兼容性。
为了实现这些目标，他们为Helm 2增加了一个新的组件——Tiller。Tiller是一个集群内部署的Pod，它负责安装和管理Chart。不过，这个组件在后面的版本中也埋下了巨大的隐患，后文会详细介绍。
自2016年Helm 2发布以后，Kubernetes也发布了很多主要特性。例如，RBAC（Role-Based Access Control，基于角色的访问控制）代替了ABAC（Attribute-based Access Control，支持属性访问控制）；许多新的资源类型加入了集群；CRD（Custom Resource Def inition，用户自定义资源）替换了TPR（Third Party Resource，第三方资源定义），一组最佳实践逐渐浮出水面。
添加了许多新特性的Helm 2上市后，便很好地满足了用户的新需求。但是用户对安全性的要求越来越高，同时用户的操作熟练度与专业性也越来越强，Helm 2渐渐无法满足用户日益增长的需求，于是2019年，Helm 3面世了。