标签：

一、背景

Kubernetes(k8s)是一个基于容器技术的分布式架构领先方案。它在Docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。
在容器云环境及容器化服务在业界开始大规模部署应用的前提下，Kubernetes在业界的实际应用情况又是怎样的呢？在今年召开的JFrog SwampUp用户大会上，Codefresh公司为大家展示了一些有意思的数据。如下图：

据Codefresh公司统计，在目前JFrog的企业用户当中，有80%已经使用了Kubernetes，这说明Kubernetes已经得到了业界的认可并开始了广泛的应用。然而，只有5%的JFrog用户在生产环境中使用Kubernetes。也就是说，企业更多的只是在自己的研发、测试环境中去使用 Kubernetes。这是什么原因呢？JFrog通过自身在Kubernetes应用上的大量实践证明，“Kubernetes is hard”，直接使用Kubernetes去部署和管理容器化的云服务，尤其是基于微服务的云服务，是非常具有挑战性的工作。
那如何才能更便捷地应用Kubernetes呢？JFrog选择了Helm，Kubernetes的官方包管理工具。我们再来看Codefresh提供的另一组数据，如下图：

和上一组数据一样，只有5%的JFrog企业用户在生产环境使用了Kubernetes。但同时，也有5%的JFrog用户使用了Helm。可见，当把Kubernetes应用到生产环境的时候，众多企业也和JFrog一样，选择了Helm这一“利器”。
为什么Helm会受到这样的青睐？本文将通过JFrog实施Helm和Kubernetes的实践来介绍和分析Helm的优势所在。

二、Helm是什么

在介绍Helm之前，我们先来看看直接应用Kubernetes部署云服务会遇到哪些困难。

Kubernetes使用yaml文件来描述和管理服务中各个组件的配置和部署需求，每个组件对应一个yaml文件。当下的云服务通常都是由多个组件构成的，如何配置和处理好这些组件，也就是多个yaml文件之间的关联关系，成为了Kubernetes应用的额外任务。而当云服务升级，却仅仅涉及其中一个或某几个模块时，升级模块的新yaml文件和已有yaml文件之间的关联关系就会变得更加错综复杂，从而更增加了使用Kubernetes来配置和管理升级的难度。
其次，，Kubernetes把组件的配置信息也直接记录到yaml文件当中。从描述组件的角度来讲，这种方式确实比较清晰。但是，当云服务的部署面对多个环境，如不同的开发、测试、产品环境（这也是当前比较常见的应用场景）时，要如何处理这些环境配置之间的差别？要为每个环境都开发和维护一套不同的yaml文件？这显然大大增加了应用Kubernetes的难度和工作量。
而且，Kubernetes的yaml文件本身是没有版本的概念的。那么当某次部署失败，需要回滚到上一个稳定版本时，该选择哪一套yaml文件来处理？显然，这需要很多额外的工作来处理。
那Helm是如何来解决这些问题的呢？

Helm（https://helm.sh）是Kubernetes的官方包管理工具。Helm是通过被称作Helm Chart的包来描述和管理云服务的。Helm Chart对应的是一组结构化的目录和yaml文件，而这些目录和文件大致可分为三个部分：

1、模板

在templates目录下存放着一组用来描述云服务当中各个组件的yaml文件，这和目前Kubernetes的用法类似。Helm把这些yaml文件组织在同一目录，能够很方便地了解当前云服务的组成，结构清晰且便于管理。

2、配置与依赖

templates目录下的yaml文件是不包含具体的配置信息的，只保留了对配置项（key）的引用。真正与目标环境对应的配置信息（value）是存储在values.yaml文件里的。当然，values.yaml只是存储了一些缺省的、静态的配置信息，在部署的过程中也可以动态地增加或修改这些配置信息。这种配置与应用分离的设计使得同一套templates可以方便地部署到不同的目标环境中，只需要更新values.yaml文件或部署时动态修改配置信息就可以了。
另外，针对某些已被广泛使用的云服务或组件，目前已经存在比较成熟、经过验证的Helm Chart了。当使用到这些服务或组件时，可以直接在requirements.yaml文件里描述这种依赖关系。在部署的时候，Helm会自动获取这些依赖的Helm Chart使用，并存储在charts目录。这种依赖性的设计，避免了很多重复性的工作，也使得Helm Chart的并行开发和共享成为可能。

3、版本化