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

原创成富灵动代码

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

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

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

Helm Chart

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

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

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

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

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

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

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

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

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

postgresqlUsername: dev
postgresqlPassword: password
persistence:
  enabled: false

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

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

helm install nginx bitnami/nginx

Release管理

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

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

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

helm upgrade --set metrics.enable=true nginx bitnami/nginx

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

在每次更新之前，还可以通过 helm diff 来查看新改动与当前release版本的差异。

helm diff upgrade --set metrics.enabled=true nginx bitnami/nginx

下面给出了 helm diff 命令的输出结果的示例。

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

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

继续滑动看下一个