概述
什么是helm？
helm是kubernetes里面的包管理工具，那什么包管理工具呢？其实就类似于我们用的centos的yum，ubuntu的apt一样能够快速安装、卸载、更新软件，最重要的一点是能够解决软件安装的依赖问题。
helm能帮助我们解决什么问题？
在kubernetes中，部署应用是一件非常麻烦的事情，首先你得学会kubernetes中的各种概念，deployment，service，pv，pvc……，其次你还得会写yaml文件，通过yaml文件把这些资源对象整合起来，所以这就产生了一个很大问题了，这些yaml文件的管理和执行的先后顺序怎么解决。举个简单例子，WordPress这个博客应用，主要用到k8s哪些资源对象，首先通过deployment部署应用，通过service提供统一入口，如果需要数据持久化的话还需要创建pv和pvc，还需要secret配置WordPress的帐号密码，mariadb的帐号密码，而且部署时还有依赖关系，WordPress数据是存储在mariadb里面的，所以需要mariadb先启动就绪后在启动WordPress，那helm能如何解决这些问题？首先helm可以把这些资源对象封装在一起做成一个软件包统一发包，这个软件包里面就可以解决掉服务与访问之间的依赖问题，其次helm能更加高效的共享和重用访问，比如这个mariadb，如果就通过yaml文件访问部署，那这里里面很多配置参数都写死了，如果另外一个应用通过这个yaml部署mariadb，就需要改里面的配置参数，通过helm能把这些参数做成变量的形式，通过传递变量的方式来达到复用的效果。总结如下 1、helm能通过软件包的方式将这些资源对象统一管理起来。2、helm降低了应用配置和部署的复杂性。3、helm时应用程序可以多次复用。
helm的概念
helm：命令行工具也是helm的客户端，主要用本地chart开发，chart仓库管理，与Tiller连接，release信息仓库。
chart：helm的软件包，类似于yum和apt里面的软件安装包，chart里面内含了kubernetes对象的配置模块，参数，依赖关系和说明文档。
release：是chart运行的实例，比如你通过helm将memcache这个chart部署到了这个kubernetes集群，那这个部署好的memcache就是一个release。
tiller：helm是一个c/s架构程序，tiller是helm的服务端，用于接收helm客户端的请求它与kube-apiserver交互，负责基于chart创建release和删除和release状态追踪。
Repoistory：软件仓库，就类似于yum源和apt源一样。chart就是存在这里面。
helm安装
环境信息：
os：ubuntu16.04
docker：17.03
kubernetes：1.11.2
helm：2.9.1
不同操作系统有不同安装方法https://github.com/helm/helm/releases，我这里使用ubuntu操作系统，直接下载对应的包就好了
下载helm
会发现下载不下来，因为在google那边
1 | wget https://kubernetes-helm.storage.googleapis.com/helm-v2.9.1-linux-amd64.tar.gz |
翻墙下载
1 | https://kubernetes-helm.storage.googleapis.com/helm-v2.9.1-linux-amd64.tar.gz |
解压
1 | tar -xvf helm-v2.9.1-linux-amd64.tar.gz |
1 | cd linux-amd64/ |
1 | mv helm /usr/bin/ |
安装Tiller
执行helm init
1 | helm init |
helm init 在缺省配置下， Helm 会利用 “gcr.io/kubernetes-helm/tiller” 镜像在Kubernetes集群上安装配置 Tiller；并且利用 “https://kubernetes-charts.storage.googleapis.com“ 作为缺省的 stable repository 的地址。由于在国内可能无法访问 “gcr.io”, “storage.googleapis.com”
所以这里我们换成国内阿里的repo
1 | helm init --upgrade -i registry.cn-hangzhou.aliyuncs.com/google_containers/tiller:v2.9.1 --stable-repo-url https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts |
该命令会在当前目录下创建helm文件夹即~/.helm，并且通过Kubernetes Deployment 部署tiller. 检查Tiller是否成功安装：
授权
如果k8s集群打开的RBAC的话需要给tiller用ServiceAccount运行并且给这个ServiceAccount配置clusterrolebinding，因为tiller需要直接根kube-apiserver交互需要权限
1 | kubectl create serviceaccount --namespace kube-system tiller |
1 | kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller |
1 | kubectl patch deploy --namespace kube-system tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}' |
验证
执行helm version
查看当前仓库可用的chart
1 | helm search |
部署应用测试
部署mariadb
执行
1 | helm install --name mariadb --set "persistence.enabled=false" stable/mariadb |
这里配置persistence.enabled=false是因为我环境里面没有pvc所以把持久化存储关了，将chart内的这个变量设置为false
部署完成
查看是否部署成功
删除release
1 | helm del release_name |
直接通过helm del删除release，会把对应的kubernetes资源对象删除，但release记录还是会保留下来，这时如果要还原可以直接执行
1 | helm rollback release_name revision |
虽然rollback能执行成功并且，资源也重启创建回来了，但是状态会变成PENDING_ROLLBACK,看github的issue是说rollback只能用于现有的部署，已经删除了release回滚状态会报错
https://github.com/helm/helm/issues/3722
如果需要删除时，彻底删干净，连同release记录也删除，需要添加额外参数–purge
1 | helm del --purge release_name |
helm原理
图片来源cloudman《每天5分钟玩转kubernetes》
创建release
1、helm客户端从本地tar文件或repo里面解析出chart信息。
2、helm客户端将解析出来的信息通过grpc传给tiller。
3、tiller根据传来的信息生成release，然后将install release请求直接传递给kube-apiserver。
删除release
1、helm客户端从本地tar文件或repo里面解析出chart信息。
2、helm客户端将解析出来的信息通过grpc传给tiller。
3、tiller将delete release请求直接传递给kube-apiserver。
更新release
1、helm客户端将需要更新的chart的release名称chart结构和value信息传给tiller。
2、tiller将收到的信息生成新的release，并同时更新这个release的history。
3、tiller将新的release传递给kubernetes-apiserver进行更新。
https://www.cnblogs.com/CloudMan6/p/8970314.html
https://docs.helm.sh