目前我们部署的 Kubernetes 微服务都是通过 Yaml 文件来维护的。每个微服务都需要维护⼀套 Yaml 文件， 但是每个环境下的配置文件也不太⼀样。对于单体服务，部署一套测试环境还是非常快的；但是对于微服务架构的应用，要部署一套新的环境，就非常麻烦了；微服务越多、管理越麻烦。如果我们能够使用类似于 Yum 的工具来安装应⽤的话是不是就很方便呢？ Helm 就相当于 kubernetes 环境下 的 Yum 包管理工具
一、什么是 Helm？
Helm 是 Kubernetes 的软件包管理工具。类似于我们在 Ubuntu 中使用的 apt、Centos 中使用的 Yum 或者 Python 中的 pip 一样，能快速查找、下载和安装软件包。Helm 由客户端组件 helm 和服务端组件 Tiller 组成, 能够将一组K8S资源打包统一管理, 是查找、共享和使用为Kubernetes构建的软件的最佳方式。
在 Kubernetes 中部署一个可以使用的应用，需要涉及到很多的 Kubernetes 资源的共同协作。例如我们前面讲解的 WordPress 安装部署，用到了一些 Kubernetes 的一些资源对象，包括 Deployment 用于部署应用、Service 提供服务发现、Secret 配置 WordPress 的用户名和密码，可能还需要 pv 和 pvc 来提供持久化服务。并且 WordPress 数据是存储在 MySQL 里面的，所以需要 MySQL 启动就绪后才能启动 WordPress。这些 Kubernetes 资源过于分散，不方便进行管理，直接通过 kubectl 来管理一个应用，你会发现这非常麻烦。所以我们在 Kubernetes 中部署一个应用，通常面临以下几个问题：
- 如何统一管理、配置和更新这些分散的 Kubernetes 的应用资源文件；
- 如何分发和复用一套应用模板；
- 如何将应用的一系列资源当做一个软件包进行管理。
于是 Helm 包管理工具应用而生、接下来我们来详细的看看 Helm 的概念、用途、组件、原理等内容
Helm 概念
Helm 有三个重要概念：
- chart：包含了创建 Kubernetes 的⼀个应⽤实例的必要信息
- config：包含了应⽤发布配置信息
- release：是⼀个 chart 及其配置的⼀个运⾏实例
Helm 用途
做为 Kubernetes 的⼀个包管理工具， Helm 具有如下功能：
- 创建新的 chart
- chart 打包成 tgz 格式
- 上传 chart 到 chart 仓库或从仓库中下载 chart
- 在 Kubernetes 集群中安装或卸载 chart
- 管理用 Helm 安装的 chart 的发布周期
Helm 组件
Helm 有以下两个部分组成，分别是 helm 客户端 和 Tiller 服务器：
Helm Client 是⽤户命令行工具，其主要负责如下：
- 本地 chart 开发
- 仓库管理
- 与 Tiller sever 交互
- 发送预安装的 chart
- 查询 release 信息
- 要求升级或卸载已存在的 release
Tiller Server 是⼀个部署在 Kubernetes 集群内部的 server，其与 Helm client、Kubernetes API server 进⾏交互。Tiller server 主要负责如下：
- 监听来⾃ Helm client 的请求
- 通过 chart 及其配置构建⼀次发布
- 安装 chart 到 Kubernetes 集群，并跟踪随后的发布
- 通过与 Kubernetes 交互升级或卸载 chart
- 简单的说，client 管理 charts，而 server 管理发布 release
二、Helm 安装
从 2019 年 11 月开始、Helm 就正式开始升级到了 Helm3。但是 Helm2 和 Helm3 之间还是有很大的区别。比如Helm3 中移除了 Tiller、Helm2 是 C/S 架构，主要分为客户端 helm 和服务端 Tiller; 与之前版本相同，Helm 3 同样在 Release 页面提供了预编译好的二进制文件。差别在于原先的二进制包下载下来你会看到 helm 和 tiller 。而 Helm 3 则只有 helm 的存在了。Tiller 主要用于在 Kubernetes 集群中管理各种应用发布的版本，在 Helm 3 中移除了 Tiller, 版本相关的数据直接存储在了 Kubernetes 中
下面我们就来看看 Helm3 的安装和基础使用方法
Helm项目地址：https://github.com/helm/helm/releases
首先我们去上面的 Helm Github 地址把 Helm3 的二进制包下载到本地，然后通过 tar -zxvf 命令进行解压、解压完成之后直接通过 mv 或者 cp 命令把 Helm 包移动到 /usr/local/bin/helm ，然后 Helm3 就已经安装完成了。我们可以通过 helm version 命令查看 Helm 安装版本、我这里安装的是 v3.1.2：
要安装 Helm 的服务端程序，我们需要使用到 kubectl 工具，所以先确保 kubectl 工具能够正常访问 kubernetes 集群的 apiserver。 然后我们需要先执行 helm init 来进行初始化。Helm3 的初始化就简单了很多，不再需要给集群中部署 Tiller 了。
原先，由于有 RBAC 的存在，我们在开始使用时，必须先创建一个 ServiceAccount 而现在 Helm 的权限与当前的 KUBECONFIG 中配置用户的权限相同，非常容易进行控制。这样也大大增强了使用 Helm 的安全性。至此, Helm 已经配置完成了，接下来我们看看如何使用吧（关于 Helm2 和 Helm3 的区别、我们在文末详细总结）
三、使用Helm
我们现在尝试创建一个 Chart：
我们通过查看 templates 目录下⾯的 deployment.yaml 文件可以看出默认创建的 Chart 是⼀个 nginx 服务，具体的每个文件是干什么用的，我们可以前往 Helm 官方文档进行查看，当然后面我们也会详细讲解的。比如这里我们来安装 1.7.9 这个版本的 nginx。我们直接更改 value.yaml 文件下面的 image tag 即可，将默认的 stable 更改为 1.7.9，为了测试方便，我们把 Service 的类型也改成 NodePort：
现在我们来尝试安装一下这个 Chart 。在 Helm 2 中，如果没有指定 release 的名称，则会自动随机生成一个名称。但是在 Helm 3 中，则必须主动指定名称，或者增加 –generate-name 的参数。比如：
等到 Pod 创建完成后，我们可以根据创建的 Service 的 NodePort 来访问该服务了，然后在浏览器中 打开 http://172.16.200.1:30652 就可以正常的访问我们刚刚部署的 nginx 应用了
当然我们可以通过下面的命令来操作 Helm：
查看Release：
$ helm list
打包Chart：
$ helm package hello-helm
注：我们可以将打包的 tgz ⽂件分发到任意的服务器上，通过 helm fetch 就可以获取到该 Chart了
删除Release：
$ helm delete hello-helm-1584972412
当然，还有更多关于 Helm 的使用命令，我们可以前往官方文档查看
四、Helm2 和 Helm3 的区别
Helm2 和 Helm3 的区别有下面几条：
- 移除 Tiller（前面已经讲解过了、这里不再重复）
- Release 名称可在不同 ns 间重用
- 必须指定 Release 名称
- 支持将 Chart 推送至 Docker 镜像仓库中
- 移除 helm serve
评论区