初探云原生应用管理（二）: 为何你必须尽快转向 Helm v3

系列介绍：这个系列是介绍如何用云原生技术来构建、测试、部署、和管理应用的内容专辑。作这个系列的初衷是为了推广云原生应用管理的最佳实践，以及传播开源标准和知识。在这个系列文章的开篇初探云原生应用管理（一）: Helm 与 App Hub中，咱们介绍了如何用 Helm 来快速部署 K8s 应用。在本篇文章咱们将跟你聊聊，为何要尽快转向 Helm V3。

在研究了一番“开放云原生应用中心（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 应用的文件布局以下所示：

myapp/
Chart.yaml
values.yaml
templates/
其中，Chart.yaml 里面用来写应用元数据，好比：

apiVersion: v1
name: 图书馆管理系统
version: 0.1
description: 全中国最受欢迎的图书馆管理系统
maintainers:

• name: 小张

在 templates/ 目录下，则存放小张编写好的四个 YAML 文件。

此外，小张还能够将这些 YAML 里须要修改的字段定义成“模板变量”，在部署时由 Helm 去负责注入。好比 web-deploy.yaml ：

apiVersion: apps/v1
kind: Deployment
metadata:
name: 图书馆管理系统网站
spec:
replicas: {{ .Values.replicaCount }}
template:

...
spec:
  containers:
    ...

经过上面的语法，小张就把这个 Deployment 的 replicas 值定义成了一个变量，未来就能够在部署的时候经过传参来决定这个图书馆管理系统启动后具体有几个实例了，好比，指定 100 个实例：

helm install apphub/图书馆管理系统 --set replicaCount=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 v2 的整个项目生命周期。

为何 Helm 要坚持在 K8s 放置一个 Server 端呢？

这里其中一个重要的缘由，在于 Helm 项目并不仅但愿作一个简单“ K8s 应用打包工具”。

做为一个地道的 PaaS 服务商，Deis 公司从一开始就知道“应用打包”只是本身完整拼图的入口，而 Tiller 的存在，则是让 Helm 成为将来云原生时代“新 PaaS” 的重要伏笔。

Tiller 这个服务端组件，其实至关于 Helm 在 K8s 内插入的一个应用管理控制器。有了它，Helm 不只能够很容易在 K8s 侧存储应用相关的状态，还能够基于 Tiller 在 K8s 内逐步构建出一个微型 PaaS 的功能。而且，这些功能的设立和发展，都不须要依赖于 K8s 自己的应用管理能力。

这也解释了为什么 Helm 很快就提出了 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 试图在推动的一些事情，跟 K8s 的设计发生了正面冲突。

理论上来说，Helm 只须要将应用描述文件提交给 K8s ，剩下的应用启动、发布和回滚等操做，就都交给 K8s 便可。好比在 K8s 的 Deployment 语义中，已经为用户提供了很是详细的滚动更新策略，这些都是应用描述（ YAML 文件）里的主要字段：

yaml
strategy:
type: Rolling
rollingParams:

updatePeriodSeconds: 1 
intervalSeconds: 1 
timeoutSeconds: 120 
maxSurge: "20%" 
maxUnavailable: "10%"

可是如今，Helm 本身也内置了应用的更新和回滚策略，而且它们与 K8s 的策略没有什么关系、都经过 Tiller 帮你完成。

这就让用户陷入了一种很是尴尬的境地：我到底还要不要定义和使用 K8s 的滚动更新参数了？

除此以外，Tiller 事实上还接管了其余一些的 K8s 核心功能，好比 PATCH API 的实现。这些都让用户感受到困惑，毕竟在绝大多数状况，用户都是先学习了 K8s API 而后再开始使用 Helm 的。

固然，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 相对于 Helm v2 ，还有以下一些重要变化：

Release 名字可缩小至 Namespace 范围，须要显示启用选项 --generate-name ：这进一步规范和完善了 Helm 应用的名称问题；
合并描述应用依赖的 requirements.yaml 到 Chart.yaml：进一步减少用户的学习负担
支持 helm push 到远端 Helm Hub ，支持登录认证；
支持在容器镜像 Registry 中存储 Charts：消除 Helm Hub 和 DockerHub 的重合定位
支持 LUA 语法：现有的模板变量，实际上问题很大，咱们在后续文章中会详细介绍；
对 values.yaml 里的内容进行验证；
…
关于 Helm v3 的详细解读和实例，你能够继续阅读这篇《深度解读Helm 3: 犹抱琵琶半遮面》来一探究竟。

经历了这样的重构以后，Helm v3 已经开始调整本身的发展方向，淡化了作一个“微型 PaaS”的思路，更多的关注于应用打包和基础管理功能，将更多的自由度和发挥空间交换给了 K8s 社区。

这个变化，不管是对于 Helm 社区仍是云原生应用开发者来讲，都是喜闻乐见的。不难预料，Helm v3 很大几率会成为将来云原生应用管理体系中的一个重要工具，而与之相对应的 App Hub ，也会成为云应用分发与托管过程当中的重要环节。

云原生时代，你还有什么理由不去尝试一下 Helm v3 呢？

即刻开始！
虽然还有一些疑惑，小张彷佛也摸索出了 Helm v3 背后的一些“大计划”。

说干就干！

因为 Helm v3 如今还在预览版，没有正式的下载渠道，小张只能打开 GitHub 从 Release 页面下载二进制文件。然而 …………

“怎么会这么卡！”

因为不可描述的缘由，GitHub 托管 Release 的存储在国内访问很是困难。不过，善于利用 百度搜索的小张，仍是找到了好心人在国内托管的 Helm v3 镜像和安装方法：

https://github.com/cloudnativ...

在有了 Helm v3 以后，小张到底能不能顺利的把“图书馆管理系统”作成 Charts ，上传到开放云原生应用中心（AppHub）让全国的开发者使用到呢？

咱们拭目以待！

做者简介: 张磊，阿里云容器平台高级技术专家，CNCF Ambassador （CNCF 官方大使），Kubernetes 项目资深成员与维护者，曾就任于 Hyper、微软研究院（MSR），如今负责 Kubernetes 技术及上下游相关工做。