【云原生|K8s系列特别篇】：一文速通实战Helm管理工具
本期文章是K8s特别篇，主要是速通学习Helm之简介、仓库、实践应用等。通过本期文章：我们将学习Helm的基础知识、简介、仓库、实践应用等
在前期的文章中，已经介绍了一些云原生入门的知识及简单实战，感兴趣的同学可以去我的云原生专栏中学习，任意门：云原生学习专栏
一文速通Helm之简介、仓库、实践应用等
- 开山之词：Helm是什么？
- 中流砥柱：为什么需要Helm？
- 以一敌百：深入了解Helm架构
-
- 1、Helm客户端
- 2、Tiller服务器
- 3、chart
- 核心概念：Helm的三大法宝
- 如日中天：实战Helm Demo
开山之词：Helm是什么？
用过Ubuntu和CentOS的同学都不陌生，Ubuntu下的ap-get或者CentOS下的yum，都是Linux系统下的包管理工具。采用这两个管理工具，开发者可以管理应用包之间的依赖关系，发布应用，同时用户可以以简单的方式查找、安装、升级、卸载应用程序。
那么通过类比，Helm就是Kubernetes的apt-get/yum。Helm是Deis开发的一个用于kubernetes的包管理器。每个包都称为一个Chart，一个Chart是一个目录。
应用发布者可以通过Helm打包应用，管理应用依赖关系，管理应用版本并发布应用到软件仓库。
使用者可以使用Helm但是并不需要了解K8s的Yaml语法并编写应用部署文件，可以通过Helm下载并在kubernetes上安装需要的应用。也就是通过Helm可以使用一条命令就能够将其部署安装在自己的Kubernetes集群中。Helm还可以提供软件部署、删除、升级、回滚应用等功能。
中流砥柱：为什么需要Helm？
先来看看直接应用Kubernetes部署云服务可能会遇到的困难？
Kubernetes使用yaml文件来描述和管理服务中各个组件的配置和部署需求，每个组件对应一个yaml文件。云服务通常都是由多个组件构成的，如何配置和处理好这些组件即多个yaml文件之间的关联关系，成为了Kubernetes应用的必须面对的。
当云服务升级只涉及其中一个或某几个模块时，升级模块的新yaml文件和已有yaml文件之间的关联关系会变得更加复杂，增加了使用Kubernetes来配置和管理升级的难度。
另外，Kubernetes把组件的配置信息也直接记录到yaml文件当中。从描述组件的角度来讲，这种方式确实比较清晰。但是，当云服务的部署面对多个环境，如不同的开发、测试、产品环境（当前比较常见的应用场景），要如何处理这些环境配置之间的差别呢？为每个环境都开发和维护一套不同的yaml文件？这显然增加了许多工作量。
并且，Kubernetes的yaml文件本身是没有版本的概念的。当某次部署失败，需要回滚到上一个稳定版本，该选择哪一套yaml文件来处理也成了需要解决的额外问题。
所以，Helm可以很好的解决这些问题。Helm是通过被称作Helm Chart的包来描述和管理云服务的。
以一敌百：深入了解Helm架构
Helm的架构由Helm客户端、Tiller服务器端和Chart仓库所组成；Tiller部署在Kubernetes中，Helm客户端从Chart仓库中获取Chart安装包，并将其安装部署到Kubernetes集群中。
1、Helm客户端
Helm客户端：这是一个供终端用户使用的命令行工具，客户端负责如下的工作：
- 本地chart开发、管理仓库
- 与Tiller服务器交互，如：发送需要被安装的charts、请求关于发布版本的信息、请求更新或者卸载已安装的发布版本
Helm客户端是使用Go语言编写的，它通过gRPC协议与Tiller服务器交互。
2、Tiller服务器
Tiller服务部署在Kubernetes集群中，Helm客户端通过与Tiller服务器进行交互，并最终与Kubernetes API服务器进行交互。 Tiller服务器负责如下的工作：
- 监听来自于Helm客户端的请求
- 组合chart和配置来构建一个发布
- 在Kubernetes中安装，并跟踪后续的发布
- 通过与Kubernetes交互，更新或者chart
Tiller服务器也是使用Go语言编写的，它使用Kubernetes客户端类库与Kubernetes进行通讯。
3、chart
先简单创建个chart：
helm create myapp
//chart的目录结构
# tree myapp/
myapp/
├── charts
├── Chart.yaml
├── templates
│ ├── deployment.yaml
│ ├── _helpers.tpl
│ ├── ingress.yaml
│ ├── NOTES.txt
│ ├── serviceaccount.yaml
│ ├── service.yaml
│ └── tests
│ └── test-connection.yaml
└── values.yaml
- Chart.yaml 用于描述这个 Chart的相关信息，包括名字、描述信息以及版本等。
- values.yaml 用于存储 templates 目录中模板文件中用到变量的值。
- NOTES.txt 用于介绍 Chart 部署后的一些信息，例如：如何使用这个 Chart、列出
核心概念：Helm的三大法宝
在上面的功能中，有三个重要概念要理解：
- chart：创建Kubernetes应用实例的信息集合，helm package，包含一个k8s app应用运行起来的所有要素，比如service, deployment, configmap, serviceaccount, rbac等，这些都是以template文件的形式存在，再结合values文件，最终渲染出能够被k8s执行的yaml文件；
- repository：是charts的集合，方便进行分享和分发。
- release：release是helm chart在kubernetes的一个运行实例，可以用不同的release name多次安装同一个chart，比如：当集群中需要多个redis实例，可以使用不同的配置文件安装redis chart。
那么，helm的运行流程如下：
首先，从chart仓库中获取chart，然后开发者配置自己的values文件，根据自己的运行环境对values进行修改，然后默认values文件和使用者values文件会进行一个merge，形成最终的values文件；使用最终的values文件，渲染chart的template，形成可以被kubernetes执行的yaml，最后调用kube apply提交yaml到kubernetes。
在上述的过程中，使用者只需要理解一点点配置的知识就可以完成操作，没有那么困难了。这也正是helm的核心设计理念。
如日中天：实战Helm Demo
- 1、安装helm
curl https://baltocdn.com/helm/signing.asc | sudo apt-key add –
sudo apt-get install apt-transport-https --yes
echo "deb https://baltocdn.com/helm/stable/debian/ all main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list
sudo apt-get update
sudo apt-get install helm=3.4.2-1
- 2、添加仓库，找到redis chart
添加仓库：helm repo add stable https://charts.helm.sh/stable
查看已经添加的仓库：helm repo list
搜索仓库有哪些chart：helm search repo stable
更新仓库列表到本地：helm repo update
搜索redis：helm search repo redis
查看redis chart详情：helm show chart stable/redis
查看redis values（values：相当于chart的配置文件）：helm show values stable/redis