在研究了一番“开放云原生应用中心（AppHub）”之后，程序员小张似乎已经明白了“云原生应用”到底是怎么一回事情。
“不就是 Helm 嘛！”
这不，小张这就准备把自己开发多年的“图书馆管理系统”通过 Helm 打包成 Charts，提交到 AppHub 上个线试试。
“这样，全中国的开发者就都能使用到我开发的图书馆管理系统了！”
想想还有点小激动呢！
然而，还没等编译完，小张就发现 Helm 官方文档上有这么一句提示非常辣眼睛：
这，到底是咋回事儿？
Helm 项目的缘起
Helm 是目前云原生技术体系中进行应用管理最被广泛使用的开源项目，没有之一。根据 CNCF 刚刚发布的 KubeCon EU 2019 的总结报告，Kubernetes（k8s），Prometheus 和 Helm 这三个项目，再次蝉联 KubeCon 上最被关注的开源项目前三名。
Helm 项目本身的发布，则要追述到 Deis 还是一家独立创业公司的时代。
2016 年，容器 PaaS （所谓的 CaaS）创业方兴未艾，但也开始呈现出同质化竞争和低附加值的种种苗头，而在这片红海当中，当时已经委身卖给 Engine Yard 的 Deis 尤其步履维艰。幸运的是，敏锐的技术嗅觉在最困难的时刻拯救了这个的团队。 2016 年底，Deis 开始全面转向 K8s 体系，很快就发布了一系列专门为 k8s 进行应用管理的开源项目。这其中，定位为“k8s 应用包管理器”的 Helm，是最受欢迎的一个。
我们知道，K8s 本身是没有“应用”这个概念的。比如，小张要在 K8s 上部署的“图书馆管理系统”，实际是由四个 YAML 文件组成的：
web-deploy.yaml，用 K8s 的 Deployment 描述的 Java Web 程序；
web-svc.yaml，用 K8s 的 Service 描述的程序访问的入口；
mysql.yaml，用 K8s StatefulSet 描述的 MySQL 实例；
mysql-svc.yaml，用 K8s Service 描述的 MySQL 实例的访问入口。
然后，小张需要执行四次 kubectl apply -f 把这些 YAML 文件都提交给 K8s 来负责运行和管理这个应用。这里面的麻烦之处在于，怎么样去管理这个应用对应的所有 k8s 资源？
于是 Helm 项目提供了一种简单的思路：它定义了一种新的应用打包格式叫 Chart。一个 myapp 应用的文件布局如下所示：
其中，Chart.yaml 里面用来写应用元数据，比如：
在 templates/ 目录下，则存放小张编写好的四个 YAML 文件。
此外，小张还可以将这些 YAML 里需要修改的字段定义成“模板变量”，在部署时由 Helm 去负责注入。比如 web-deploy.yaml：
通过上面的语法，小张就把这个 Deployment 的 replicas 值定义成了一个变量，将来就可以在部署的时候通过传参来决定这个图书馆管理系统启动后具体有几个实例了，比如，指定 100 个实例：
最后，Helm 项目允许你把上面这一系列文件和目录，做成一个压缩包上传到网上，从而被别人通过 helm install 下载安装到。这个上传的地址，就是 Helm Hub 了。
这种应用打包的方法，很大程度上解决了 K8s 应用管理能力缺失的问题，所以在推出之后就很快赢得了开发者的青睐。而 Helm Hub 也成为了继 Docker Hub 之后云原生技术体系里第二个重要的应用分发中心。
Helm 的架构问题
不过，上面这个流程听起来很简单，但是 Helm 在项目的一开始设计中，却使用了一种让人“匪夷所思”的架构。
可以想象，无论是安装还是更新应用，Helm 其实都可以在客户端调用 K8s API 来完成这些功能。但现实情况是，Helm 一定需要在 Kubernetes 集群里部署了一个叫做 Tiller 的 Server 端，然后把请求都提交给 Tiller，再由 Tiller 去跟 K8s APIServer 进行交互，完成应用的安装操作，这个复杂的过程，可以用下图表示清楚：
图片来源：Helm 官方文档
而这个“画蛇添足”的架构，不但成为了 Helm 发布之处的一个假设，也贯穿了 Helm v2 的整个项目生命周期。
为什么 Helm 要坚持在 K8s 放置一个 Server 端呢？
这里其中一个重要的原因，在于 Helm 项目最初并不只希望做一个简单“应用包管理工具”。
作为一个地道的 PaaS 服务商，Deis 公司从一开始就知道“应用打包”只是自己完整拼图的入口，而 Tiller 的存在，则是让 Helm 成为未来云原生时代“新 PaaS” 的重要伏笔。
Tiller 这个服务端组件，其实相当于 Helm 在 K8s 内插入的一个应用管理控制器。有了它，Helm 不仅可以很容易在 K8s 侧存储应用相关的状态，还可以基于 Tiller 在 K8s 内逐步构建出一个微型 PaaS 的功能。并且，这些功能的设立和发展，都不需要依赖于 K8s 本身的应用管理能力。
这也解释了为何 Helm v2 为什么将很多原本可以在客户端上实现的功能都放到 Tiller 中，并且很快就提出了 Release 的概念，发布了 helm upgrade、 helm rollback 等应用升级和回滚的能力。这些设计，其实都与 Helm 最终 PaaS 化的思路有着千丝万缕的联系。
Helm v3：“迫不得已”，与“势在必行”
不过，Helm 的这条演进路线，在 Kubernetes 这个天生以“应用”为中心的基础设施体系里，却栽了个跟头。
我们知道，Kubernetes 是围绕着声明式 API 来设计的。Kubernetes 的容器编排理念以及 APIServer 实现与扩展机制，其本质目的都是为了帮助用户屏蔽掉基础设施管理的复杂性，允许用户通过统一而整洁的声明式 API 来描述自己的意图和诉求，这正是 Kubernetes 成为“The Platform of Platform”的重要基础。
这也是为何，Kubernetes 从一开始就对容器进行组合，以便借助 Pod 的概念来模拟进程组的行为；并且坚持使用声明式 API 搭配控制器模型来进行应用编排，通过 API 资源对象的创建与更新（PATCH）来驱动整个系统的持续运转。
这种设计的最终效果，就是用户只需要将一个“描述”应用的 YAML 文件，放在 etcd 里存起来，然后通过控制器模型驱动整个基础设施的状态不断地向用户声明的状态逼近，就也就是 Kubernetes 的核心工作原理了。这套理论，正是 Google Borg/Omega 进行应用管理和编排的核心与基础，同时也是 K8s 同 Mesos 这种资源管理器项目最大的区别。
这时候，我们也就不难发现。Helm 试图依托 Tiller 推进的应用生命周期管理功能，跟 K8s 的设计发生了冲突。
理论上来讲，Helm 只需要将应用描述文件提交给 K8s，剩下的应用启动、发布和回滚等操作，就都交给 K8s 即可。比如在 K8s 的 Deployment 语义中，已经为用户提供了非常详细的滚动更新策略，这些都是应用描述（YAML 文件）里的主要字段：
但是现在，Helm 自己也内置了应用的更新和回滚策略，并且它们与 K8s 的策略没有什么关系、都通过 Tiller 帮你完成。这种“喧宾夺主”的体验，让不少人尤其是资深 K8s 用户对 Helm 项目望而却步。
另一方面，Tiller 的存在，导致 Helm v2 从一开始就引入了很多“奇葩”的设计。
比如，在 Helm v2 中，应用名称（Release Name）必须是个全局唯一的名字，而不是像正常的 K8s API 资源一样，是被 Namespace 隔离开的。
这是因为 Helm 通过一个 Release 对象来记录 Release 的信息，而运行在 K8s 端的 Tiller 要能够访问 Release 对象，就必须保证该对象必须和 Tiller 在同一个 Namespace ，这就导致了全集群的 Release 名字都不能重复。
这个问题，在 Helm v3 中终于得以被修复了。类似的，Helm 的 Revision（应用版本）在 v2 中也是一个全局对象，而现在在 v3 中，一个应用终于可以由自己的 Revision 对象，并且每次升级或者回滚时关联到对应的 Revision 即可。
不过，现在回头来看，Helm 项目当初走向这样的架构，其实也是可以理解的。
在 2016~2017 年，应用管理并不是 K8s 主要透出来的核心能力，很少有人能够意识到 K8s 异常复杂的声明式 API 、尤其是 PACTH API 到底意味着什么————哪怕“K8s 声明式应用配置”的大部分理论实际上一直存在于 K8s 文档库最不显眼的一个角落中。所以，在那个时候，大家在 K8s 之上进行应用管理第一个想到的 idea，基本都是在 K8s 里安装一个 Controller 来实现。实际上，当时 Google Cloud 团队自己也提出了一个叫做 Deployment Manager 的插件，这个插件后来跟 Tiller 部分合并在了一起。
但开源社区魔力就在于用户“用脚投票”的神奇力量。
Helm 项目作为 “K8s 包管理工具”的设定，让这个项目在云原生社区风生水起；但与此同时， Tiller 这个奇怪的存在，也成为了 Helm 项目进一步向前发展的绊脚石。长久以来，Tiller 组件带来的使用困惑、安全隐患、部署维护的复杂度，几乎占据了 Helm 社区的绝大多数板块。一些厂商甚至干脆自己发布了“去 Tiller 版”的 Helm 发行版来表示“抗议“。
而另一方面， K8s 的声明式应用管理思路也没有走向外置 Controller 的方式去解决，而是选择继续在 K8s 本身去丰富和完善应用管理与发布能力，这很快也成为了整个 K8s 社区投入的重中之重（这个故事，我们在后续的《云原生应用管理系列文章》中会为你进行进一步的介绍）。这也就使得 Helm 本身内置的应用管理体系开始与上游社区渐行渐远。
当生态和社区都开始与项目的发展背道而驰的时候，“自我革命”就自然成为了一个势在必行的选择。
Helm v3，云原生应用管理的重要里程碑
除了移除 Tiller、让 Helm 变成纯客户端工具之外，Helm v3 相对于 v2，还有如下一些重要变化：
Release 名字缩小至 Namespace 范围：
Triller 移除后，Release （应用）名称和 Revision（版本）不再是全局值，用户可以非常自然的在不同 namespace 里使用相同的 Release 名字；
合并描述应用依赖的 requirements.yaml 到 Chart.yaml：
进一步减小用户的学习和使用 Helm 进行应用包管理负担
支持 helm push 到远端 Helm Hub，支持登陆认证；
支持在容器镜像 Registry 中存储 Charts：
消除 Helm Hub 和 Docker Registry 的重合定位
支持 LUA 语法：
Helm 现有的模板变量的参数定义方法，实际上有很多问题，我们在后续文章中会详细介绍；
可以对 values.yaml 里的内容进行验证（Validation）；
…
关于 Helm v3 的详细解读和实例，你可以继续阅读这篇《深度解读Helm 3: 犹抱琵琶半遮面》来一探究竟。
经历了这样的重构之后，Helm v3 已经开始调整自己的发展方向，淡化了做一个“微型 PaaS”的思路，更多的关注于应用打包和包管理这两个核心功能上，将更多的应用管理的自由度交换给了 K8s 社区。
这个变化，无论是对于 Helm 社区还是云原生应用开发者来说，都是喜闻乐见的。不难预料，Helm v3 很大概率会成为未来云原生应用管理体系中的一个重要工具，而与之相对应的 App Hub，也会成为云应用分发与托管过程中的重要环节。
如果更向前延伸一些，未来在 K8s 上部署应用，很可能上只需要提交一个应用定义即可。这个应用定义，很大程度上会是类似 Helm Charts 这样的、自包含的应用描述文件，用户在客户端就可以完成这个应用的设置和配置，然后提交给 K8s。接下来，这个应用的创建、更新和发布流程，就都可以由 K8s 以及它所集成的应用服务能力（比如 OpenKruise、Tekton、Istio 和 Knative） 来完成。这种工作形态，很可能正是面向未来的、“云原生应用”的最终走向。
云原生时代，你还有什么理由不去尝试一下 Helm v3 呢？
即刻开始！
虽然还有一些疑惑，小张似乎也摸索出了 Helm v3 背后的一些“大计划”。
说干就干！
由于 Helm v3 现在还在预览版，没有正式的下载渠道，小张只能打开 GitHub 从 Release 页面下载二进制文件。然而 …………
“怎么会这么卡！”
由于不可描述的原因，GitHub 托管 Release 的存储在国内访问非常困难。不过，善于利用“百度搜索”的小张，还是找到了好心人在国内托管的 Helm v3 镜像和安装方法：
在有了 Helm v3 之后，小张到底能不能顺利的把“图书馆管理系统”做成 Charts，上传到开放云原生应用中心（AppHub）让全国的开发者使用到呢？
我们拭目以待！
相关文章：
评论