为什么必须尽快转向，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。
我们将跟你聊聊，为什么要尽快转向 Helm V3。
在研究了一番“开放云原生应用中心（AppHub）”之后，程序员小张似乎已经明白了“云原生应用”到底是怎么一回事情。
“不就是 Helm 嘛！”
说话间，小张就准备把自己开发多年的“图书馆管理系统”通过 Helm 打包成 Charts ，提交到 AppHub上个线试试。
“这样，全中国的开发者就都能使用到我开发的图书馆管理系统了！”
想想还有点小激动呢！
然而，还没等编译完，小张就发现 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 其实都可以在客户端调用 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 的这条演进路线，在 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 本身内置的应用管理体系开始与上游社区渐行渐远。
当生态和社区都开始与项目的发展背道而驰的时候，“自我革命”就自然成为了一个势在必行的选择。
除了移除 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 已经开始调整自己的发展方向，淡化了做一个“微型 PaaS”的思路，更多的关注于应用打包和基础管理功能，将更多的自由度和发挥空间交换给了 K8s 社区。
这个变化，无论是对于 Helm 社区还是云原生应用开发者来说，都是喜闻乐见的。不难预料，Helm v3 很大概率会成为未来云原生应用管理体系中的一个重要工具，而与之相对应的 App Hub ，也会成为云应用分发与托管过程中的重要环节。
云原生时代，你还有什么理由不去尝试一下 Helm v3 呢？
看完上述内容，你们掌握为什么必须尽快转向的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注亿速云行业资讯频道，感谢各位的阅读！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
