Helm如何解决Kubernetes中部署应用的问题
这篇文章将为大家详细讲解有关Helm如何解决Kubernetes中部署应用的问题，文章内容质量较高，因此小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。
一、背景
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的产品和相关工具搭建了自己产品的流水线并广泛使用。
关于Helm如何解决Kubernetes中部署应用的问题就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
