在云原生的架构时代，K8S已经成为云原生默认的云操作系统了。由于占据了绝大部分市场份额，它已经成为了一种标准。
在考虑将自己的架构部署在云环境时，我们更多是考虑如何让它在K8S上顺利的部署与运行。至于K8S是基于哪个Linux操作系统，背后的操作系统用的又是什么虚拟技术，这些都不在我们架构的关心范围之内了。
所以，K8S成为了云时代的标准操作系统。
今天，我要讲的就是K8S云操作系统之上的包管理技术--Helm
Helm是什么
Helm是K8S的包管理器。如果需要进行类比，你可以把它理解成为Linux操作系统上的APT，YUM等包管理工具。
为什么K8S需要一个包管理器？
因为部署应用的复杂性。
虽然K8S已经是声明式部署了，比之过往的命令式部署已经前进了一大步。但考虑到云架构大多具有模块多，再结合K8S的概念也多，把一个云原生架构部署到K8S上，这个过程并不简单。
- • 你需要为每个微服务编写对应的deployment以及Service的配置文件
- • 对这些微服务你得一个一个的
kubectl apply -f xxx.yml这个过程来进行声明式部署 - • 通常都会有很多的configMap变量，你又得编写对应的yml，再执行部署
- • 每次更新或升级，这些过程得重复来一次
这意味着，部署一个云原生架构，并不简单。过程可能非常麻烦。
再假设一下，如果你的产品，并非只部署一份，有可能是客户购买一份，你就得部署一次，那光是这个产品的部署工作量，也是非常大的。
那能不能简化这个过程，用一个命令解决？
可以的，这就是Helm解决的问题。
Helm的主要概念
Helm是一个应用包管理器，这意味着，它和YUM,APT这些包管理工具非常类似，只需要你提前编写好符合Heml规范的应用配置文件，就可以使用一个命令就完成一个应用的部署。
是不是非常方便？能在很大程序上减少基于K8S云原生应用部署的复杂性。
Heml主要是由三个核心概念组成：
- 1. Helm Chart
一个Chart就是一个应用，比如你有一个叫xx产品，那你可以为它制定一个Helm Chart。当然，一个Charrt本质上就是一个目录，里面有很多子目录与配置文件。
Chart是有版本历史的，这是支持进行应用的升级与回退管理等。
- 2. Helm Repository
Helm仓储。当然是存放Chart的仓储了。你定制好了一个Chart，就需要上传到Repository，然后在部署时，你从Repository中下载Chart，就可以在K8S上进行安装了
Helm有一个官方Repository，当然也是你也可以部署自己的Repository了。
- 3. Helm Release
一个Release就相当于一个应用部署了。每个Release都对应着当前Chart中定义的版本，信息等。后续你可以升级或回滚，当然也可以在另外的地方部署一个新的Release。
Helm Chart的目录结构
一个最简单的Helm Chart的目录结构大致参考为：
代码语言：javascript复制bank
├── Chart.yaml
├── values.schema.json
├── values.yaml
├── charts
├── templates
│ ├── NOTES.txt
│ ├── _helpers.tpl
│ ├── deployment.yaml
│ ├── ingress.yaml
│ ├── service.yaml- •
Chart.yaml: chart的描述文件，包含此chart的名称，版本信息，维护者等。 - •
values.schema.json: 定义此chart能接受的变量，比如数据库的用户名，密码等 - •
values.yaml：变量的默认值文件，安装Chart时，可以指定自己的变量设置。没有指定则使用此文件中的默认值。 - •
charts: 依赖声明，一个chart可以声明依赖另一个chart - •
templates: K8S各种配置文件所在目录，你的deployment,Service或其它。这里的文件可以结合values中的变量来进行定义，甚至支持一些模板语言，比如if，for等
所以，所谓的helm chart，无非就是一些目录与文件，你按照它的规则去定义就可以了。同理，所谓的APT包，YUM包都是这个模式。
有了这份chart，你部署一个K8S应用就简单至级了。
代码语言：javascript复制部署chart
helm install my_xx repository/xx代码语言：javascript复制升级chart
helm upgrade my_xx repository/xx如果对于chart，你想验证你定义是否正确，使用如下命令
代码语言：javascript复制helm lint .私有Repository
其实，使用Helm，一样会遇到另一个问题，就是Repository的可访问性问题。这个与镜像的registry是同一个问题。
在很多企业内部，访问一个互联网的Repository是一个网络安全上不被接受的点。所以使用Helm，对很多企业来说，这一点是需要应对与解决的困难。
当然，好在肯定也有解决方案了。
首先，你得清楚，所谓的Repository无非是一个提供HTTP/HTTPS静态文件访问的地址而已。也就是，只要通过http能访问或下载到chart的打包文件就可以了，你完全可以自己使用nginx来实现一个仓储。
不过，这并不是最快的方式，考虑到如果你需要支持上传chart，使用chartmuseum是最快捷的，还支持本地目录。
chartmuseum是Helm官方提供的一个搭建私有Repository的工具，你可以在公司内部，甚至是本机上搭建一个Repository。
代码语言：javascript复制部署一个简易的本机repository
chartmuseum --port=8080 --storage="local" --storage-local-rootdir=/heml/repository是不是非常简单，你当然也可以在公司级别或项目组级别搭建一个repostiory来使用。
云原生必备技能
对于云原生模式下的部署来说，学习与熟悉Helm我认为是一个非常有价值的能力，使用Helm再结合K8S的声明式部署，才能真正做到简单，快捷，方便。
如果你是在K8S上部署，那Helm这个技术你应该要考虑认真学习与使用它。
