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回馈到社区。