一、背景
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 、版本化
每一个Helm Chart 包都可以在Chart.yaml 文件里定义自己的版本。另外，每一次 Helm 的部署都会自动生成一个版本（release ）。使用Helm 的命令，可以方便地实现这些已部署版本的查询、升级、回滚和其他管理任务。
三、 Helm 的应用实践
通过上面对 Helm 的介绍和分析可以看出， Helm 能够很好地解决 Kubernetes 应用部署的难题。 JFrog 在自己的 Kubernetes 实践当中也充分使用了 Helm 。
目前，在JFrog 各个产品自身的CI/CD 流水线上都使用Helm 进行Kubernetes 上的部署，已经可以实现每周100+ 不同产品线的任意版本组合部署，每次部署超过50 种微服务。JFrog 也将为客户提供这些Helm Chart ，以帮助客户在Kubernetes 环境快速部署JFrog 的各种产品。
在实践Helm 的过程中，JFrog 也积累了一些经验和最佳实践。
1 、配置与应用分离
针对所有的环境使用同样的Helm Chart ，但是根据不同的环境配置自己特定的values.yaml 文件。同时，根据目标环境的变化对这些values.yaml 文件进行版本化的管理。
2 、善用依赖
目前已经有很多产品和通用组件都实现了比较完善、经过验证的Helm Chart ，可以在 https://hub.kubeapps.com 里找到。我们在开发自己的Helm Chart 时，可以通过定义依赖来充分地利用这些已有的成果，在减少工作量的同时，也能提高产品的质量。
3 、在实际部署前检查Helm Chart
Helm 提供了很多实用的命令来帮助我们在实际部署之前检查Helm Chart 里的错误，降低使用的风险。比如：
·
helm lint
helm lint 可以用来检查下载的Helm Chart 是否存在问题
·
helm install –debug –dry-run
helm install 带上dry-run 参数可以在不实际执行部署的情况下检查Helm Chart 的各种配置是否正确
Helm 的各种命令及其具体用法请参考Helm 的官方文档， https://docs.helm.sh 。
4 、充分利用社区的力量
目前有很多开发者都在研究和实践Helm ，我们应该充分利用他们的经验和成果，并积极地和他们沟通交流，从而提升我们使用Helm 的效率和质量。
常用的用于 Helm 交流的社区包括：
· GitHub issues: https://github.com/helm/charts/issues
· Slack: #helm-users room in the Kubernetes Slack ( https://kubernetes.slack.com/ )
· Slack: #helm-dev room in the Kubernetes Slack ( https://kubernetes.slack.com/ )
四、 Helm 仓库
下图是 Helm 的应用架构：
其中，Tiller 部署在Kubernetes 环境中，执行应用部署等操作。而Helm 作为客户端，完成Helm Chart 的管理和部署任务的发布。在这个架构中，Helm 仓库（Storage ）保存了Helm 部署所需要的各种Chart 文件、依赖包和配置信息，在Helm 部署过程中起到了十分重要的作用。
JFrog 的Artifactory 产品，作为全球唯一提供Helm 仓库支持的统一制品管理仓库，可以在为Helm Chart 提供仓库支持的同时，为相关制品，如docker 镜像、版本化的配置信息，以及各种依赖制品等提供一站式的统一服务和管理。而JFrog 的Xray 产品，集成Artifactory 的统一制品仓库，能够实现安全漏洞的自动扫描及漏洞的影响范围分析。
有关JFrog 产品的详细介绍、能力分析及用户案例，请参考本公众号的系列文章和官网的相关介绍（ http://jfrogchina.com ）。
五、总结
通过Kubernetes 部署云服务已经在业界的到了广泛的应用。Helm 通过其统一管理、配置与应用分离、版本化等特性能够大大降低Kubernetes 部署的难度，提升部署的效率和质量，也逐渐得到了众多的关注和应用。
JFrog 的Artifactory 和Xray 等产品能够提供包含Helm 仓库在内的统一制品仓库管理和安全漏洞扫描，在实现基于Helm 的CI/CD 流水线和自动化部署方案起到了重要的作用。Codefresh 公司就利用JFrog 的产品和相关工具搭建了自己产品的流水线并广泛使用。
