【本文目标】
- Helm以及Helm Chart介绍
- Helm Version 2和3的区别
【前置文章】
- 【k8s学习】Kubernetes学习——核心组件和架构
- 【k8s学习】minikube、kubectl、yaml配置文件的介绍
- 【k8s学习】在minikube上布署MongoDB和MongoExpress
- 【k8s学习】kubernetes namespace介绍
- 【k8s学习】Kubernetes Ingress介绍
1. Helm介绍
1.1 Package Manager for Kubernetes
Helm是k8s上的包管理工具。类似apt, yum, homebrew。
举个例子，如果我们要往Kubernetes集群中部署myapp项目，那么可能需要：
- Stateful Set：如db数据库。
- ConfigMap
- Secret
- K8s Users
- Service
- ...
也许这些配置别人也同样做过，所以我们的目标是能复用这些yaml以达到减少自己写yaml的目标。而这些bundle yaml（yaml的集合），即为Helm Charts。
我们可以创建自己的Helm Charts，然后push到Helm的Repository上。也可以下载别人的Helm Chart，如一些db配置（MongoDB, MySQL, Elasticsearch...），或是监控类配置（Promotheus），诸如此类复杂的Chart配置，在Repository上都已经有了。
Sharing Helm Charts——这种分享的方式，也让Helm成为热门项目的原因之一。
如何搜索：
- 通过命令`helm search <keyward>
- Helm Hub UI，search
除了Public Repository，有些公司会有自己的Private Helm Repository。
1.2 Templating Engine
如果有多个micro-service，每个micro-service都有自己的Pod yaml定义（大多数时候这个yaml定义都长的差不多，只有少部分field不一样），Helm的做法是把这些定义抽象成一个模版，那些不一样的field可以参数化。
模版定义例如：
apiVersion: v1
kind: Pod
metadata:
name: {{ .Values.name }}
spec:
containers:
- name: {{ .Values.container.name }}
image: {{ . Values.container.image }}
port: {{ .Value.container.port }}
上述的{{ .Values... }}来自于另外的文件，叫values.yaml，在这个文件中我们传入的是真实的值：
name: my-app
container:
name: my-app-container
image: my-app-image
port: 9001
使用模版驱动的配置对CI/CD比较有好处，在build的时候替换真实的values。
1.3 不同环境下的配置可以使用Helm
当我们的项目部署在不同环境下（如Dev，Test，Prod等），配置可能都长的差不多，这时候也可以使用Helm Chart来打包。
2. Helm Chart学习
一般来说Helm Chart的目录结构会是：
mychart/：mychart文件夹，以chart的名字命令，在这个文件夹下面，会有以下文件或是文件夹：
-
Chart.yaml：mychart metadata相关的信息，比如name, version，dependencies等 -
values.yaml：templates模块需要被替换的真实的值，这里一般存放的是默认值，可以被重写掉的。 -
charts/：这个文件夹放的是charts的一些依赖，比如当前的chart依赖于别的chart，那么别的chart就可以安装在这里面。 -
templates/：文件夹用来存放模版。 -
...：其它的一些文件，例如readme.txt或是licence文件等。
当使用命令helm install <chartname>来安装上述chart时，模版文件中的yaml模版里的参数将会被values.yaml替换掉，进而生成Kubernetes认识的yaml。
在mychart文件夹中的values.yaml，是默认的values.yaml，可以被重写掉，那么怎么进行重写呢？
- 方式1是在安装的时候传入value文件名，如：
helm install --values=my-values.yaml <chartname> - 方式2可以在安装的时候直接传入值，如
helm install --set version=2.0.0 <chartname>，这里的version就是template中的field名字。
3. Release Management
Helm Version 2 vs. 3
Helm Version 2有两部分：Client（helm CLI）和Server（Tiller）
Server是运行在Kubernetes集群中的，当我们在客户端使用命令helm install <chartname>进行安装的时候，请求会被发送到Server端的Tiller中。Tiller收到后会开始在Kubernetes集群中创建工作，如创建Pod，Service等。
Helm Version2的这个功能，可以帮助我们进行Release管理。
在Server端的Tiller会保存着helm的执行记录。
Tiller在Kubernetes集群中能干很多事，如创建、修改删除组件，正因为此，Tiller太过强大可能会导致一些安全问题，所以在Helm3中将Tiller移除了。
