这篇文章介绍一下云原生应用在 Kubernetes 上安装时,经常会用到的一个重要工具,Helm。
Helm 是 Kubernetes 的包管理软件。提到包管理软件,很多人都不陌生。Maven、Gradle、pip、RubyGems 和 npm 都是包管理软件。
作为一个包管理软件,核心是包和管理两个部分。
Helm Chart
第一个部分的要点是 Helm 的包中都包含什么?
我们都知道,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。
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 的开发。