Helm 入门介绍 – Kubernetes 上的包管理软件

这篇文章介绍一下云原生应用在 Kubernetes 上安装时，经常会用到的一个重要工具，Helm。

Helm 是 Kubernetes 的包管理软件。提到包管理软件，很多人都不陌生。Maven、Gradle、pip、RubyGems 和 npm 都是包管理软件。

作为一个包管理软件，核心是包和管理两个部分。

Helm Chart

第一个部分的要点是 Helm 的包中都包含什么/p>

我们都知道，Kubernetes 采用的是声明式的资源管理。以 YAML 文件的形式来声明资源的期望状态，而 Kubernetes 会确保资源的实际状态，满足声明所描述的期望。

比如，一个 Deployment 只需要声明 Pod 的数量即可，而不用去管运行时 Pod 可能会出现的由于 Pod 失败导致的 Pod 被重新创建等细节。

在部署一个应用到 Kubernetes 时，可能会需要声明多种不同的资源。比如，在安装 Postgres 时，我们可能会需要如下资源：

• 实际运行 Postgres 的 Deployment 或 StatefulSet。

• 允许其他应用访问的 Service。

• 数据存储需要的 PersistenceVolumeClaim 或 PersitenceVolume。

• 保存数据库配置的 ConfigMap。

• 保存数据库密码的 Secret。

所有这些资源声明组成了应用的安装包，Helm 称之为 Chart。

使用软件包的一个重要目的是为了共享。Helm Chart 中的资源定义是通过模板生成的，包含了很多可以在安装时进行配置的选项。以Postgres来说，你可能会需要配置数据库的访问密码、存储空间的大小和数据库的初始化脚本等。

把Helm Chart与安装时的配置项结合起来，就得到了一个特定的release。

以Postgres Chart为例，我们可以创建对应于开发、测试和生产环境的3个不同的release。每个release基于同样的Chart，但是配置不同。配置项通常以YAML文件的形式来保存，也可以在命令行传递。

下面给出了的配置文件，对应于 Postgres 在开发环境上的release。

通过  命令可以安装Chart。在安装时需要指定Chart的名称、release的名称和配置文件。配置文件使用  参数来传递，也可以使用  来设置单个配置项的值。

下面的代码使用默认的配置来安装 Nginx。

Release管理

之前说的是包的部分，下面介绍 Helm 对包的管理。每个 Helm Chart 有两个版本 ，一个是所安装的应用的版本 ，比如 Postgres 的版本 ；另外一个是 Chart 自身的版本。使用语义化的版本 ，可以保证应用的有序升级。

当创建了release之后，Helm可以对release进行管理，包括升级、回退和删除。对release的更新会产生不同的版本。比如，在首次安装了Nginx之后，release的版本为 。可以通过  命令来查看。

之后我们接到一个需求，要求启用Nginx与Prometheus的集成功能。只需要使用  命令更新当前的release，传递一个新的配置项  即可。当更新完成之后，release的版本为 。

如果发现之前的更新产生了问题，可以通过  命令，回退到版本 。需要注意的是，在执行 命令之后，release的版本 实际上变成了 。可以使用  命令来查看release的全部版本历史记录。

当需要在Kubernetes上安装软件时，第一个选项是从 ArtifactHub 上查找，看是否已经有别人贡献的Chart。这样可以极大的降低开发的成本。比如，我之前安装 Postgres 和Nginx使用的都是 Bitnami 维护的Chart。

对于内部项目的应用，只能自己开发 Chart。我将在下一篇文章中介绍 Helm Chart 的开发。

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览91537 人正在系统学习中