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 <chart path>

helm lint可以用来检查下载的Helm Chart是否存在问题

  • helm install –debug –dry-run <chart>

helm install带上dry-run参数可以在不实际执行部署的情况下检查Helm Chart的各种配置是否正确

Helm的各种命令及其具体用法请参考Helm的官方文档,https://docs.helm.sh

4、充分利用社区的力量

目前有很多开发者都在研究和实践Helm,我们应该充分利用他们的经验和成果,并积极地和他们沟通交流,从而提升我们使用Helm的效率和质量。

 

常用的用于Helm交流的社区包括:

四、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的产品和相关工具搭建了自己产品的流水线并广泛使用。

K8S中文社区微信公众号

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址