51 K8S 之 Helm 基础应用

Kustomize 的核心目标在于为管理的应用生成资源配置，而这些资源配置中定义了资源的期望状态，在具体实现上，它通过 kustomization.yaml 文件组合和（或）叠加多种不同来源的资源配置来生成。

Kustomize 将一个特定应用的配置保存在专用的目录中，且该目录中必须有一个名为 kustomization.yaml 的文件作为该应用的核心控制文件。由以下 kustomization.yaml 文件的格式说明可以大体看出，Kustomize 可以直接组合由 resources 字段指定的资源文件作为最终配置，也可在它们的基础上进行修订，例如添加通用标签和通用注解、为各个资源添加统一的名称前缀或名称后缀、改动 Pod 模板中的镜像文件及向容器传递变量等。

Helm 是一款将 Kubernetes 应用打包为“图表”格式，并基于该格式完成应用管理的工具。与 Kustomize 使用 JSON（或 YAML）与叠加机制生成最终配置有所不同的是，Helm 是一个模板引擎，它使用模板与值文件（value.yaml）来构建最终的配置清单。Helm 类似于 Linux 系统上的 yum 或 apt-get 等包管理器，可以帮助用户查找、分享及管理 Kubernetes 应用程序。

Helm 把 Kubernetes 的资源打包到一个 Chart 中，并将制作、测试完成的各个 Chart 保存到仓库进行存储和分发。Helm 还实现了可配置的发布，它支持应用配置的版本管理，简化了 Kubernetes 部署应用的版本控制、打包、发布、删除、更新等操作，它有如下几个关键概念。

Chart：即一个 Helm 程序包，它包含了运行一个 Kubernetes 应用所需要的镜像、依赖关系和资源定义等，它类似于 APT 的 dpkg 文件或者 yum 的 rpm 文件。

Repository：集中存储和分发 Chart 的仓库，类似于 Perl 的 CPAN，或者 Python 的 PyPI 等。

Config：Chart 实例化安装运行时使用的配置信息。

Release：Chart 实例化配置后运行于 Kubernetes 集群中的一个应用实例；在同一个集群上，一个 Chart 可以使用不同的 Config 重复安装多次，每次安装都会创建一个新的 Release（发布）。

用户在 Helm 客户端本地遵循其格式编写 Chart 文件，而后即可部署在 Kubernetes 集群上，运行为一个特定的 Release。仅在有分发需求时，才应该把同一应用的 Chart 文件打包成归档压缩格式提交到特定的 Chart 仓库。仓库可以运行为公共托管平台，也可以是用户自建的服务器，仅供特定的组织或个人使用。

Helm 的主流可用版本主要有 v2 和 v3 两个。版本 v2 中 Helm 主要由与用户交互的客户端、与 Kubernetes API 交互的服务端 Tiller 和 Chart 仓库（repository）组成，Helm 的客户端是一个命令行工具，采用 Go 语言开发，它主要负责本地 Chart 开发、管理 Chart 仓库，以及基于 gRPC 协议与 Tiller 交互，从而完成应用部署、查询等管理任务。而 Tiller 服务器则托管运行在 Kubernetes 上，负责接收 Helm 客户端请求、将 Chart 转换为最终配置以生成一个 Release，随后部署、跟踪以及管理各 Release 等功能。

版本 3 时代的 Helm 使用 CRD 将 Release 直接保存到 Kubernetes 之上，且无须再跟踪各 Release 的状态，而将 Chart 渲染成 Release 的功能也移往 Helm 客户端，从而不必再用到 Tiller 组件。

Helm 客户端工具支持预编译的二进制程序和源码编译两种安装方式，但它释出的每个版本都为各主流操作系统提供了适用的预编译版本，用户安装前按需下载适合的发行版本即可，大大简化了程序包的部署难度。

除了 add 和 update 之外，helm repo 命令还支持 list 和 remove 等子命令，前者用于列出本地配置的 Chart 仓库，而后者则用于移除指定的仓库。

升级或回滚应用，要分别使用 helm upgrade 和 helm rollback 命令，还可以使用 helm history 命令获取指定 Release 的变更历史。若各可用仓库中均不存在某应用相关的可用 Chart，用户可以自行编写 Chart，甚至将 Chart 回馈到社区。