Helm如何解决Kubernetes中部署应用的问题

61次阅读

共计 3970 个字符，预计需要花费 10 分钟才能阅读完成。

这篇文章将为大家详细讲解有关 Helm 如何解决 Kubernetes 中部署应用的问题，文章内容质量较高，因此丸趣 TV 小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。

一、背景

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 交流的社区包括：

· 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 的统一制品仓库，能够实现安全漏洞的自动扫描及漏洞的影响范围分析。