Helm是一个非常常用的K8s应用包管理工具,负责云原生应用的安装部署和生命周期管理。
Helm2
Helm2有两个主要的组件:
- Tiller: helm的服务端,部署在k8s里面的一个pod,通常在kube-system这个系统空间里。主要负责部署helm charts,管理release,跟k8s API通信。
- Helm Client: 主要负责从共有或者私有helm charts仓库拉取chart包,修改变量值,然后直接扔给tiller。
Helm2的问题
Helm2的一个主要问题是需要在k8s集群里面运行一个服务端,而这就需要把tiller的端口暴露给外界,会产生安全隐患。
在helm 2中引入的tiller主要是当时k8s还没有RBAC机制,所以就引入了服务端tiller。
而后来k8s的功能相应完善,加入了RBAC和CRD等,都使得tiller这个东西显得多余。
Helm3
helm3只有一个客户端,没有服务端,所以安装起来很方便,把相应的程序下下来即可,不需要helm init安装了。
相对于helm2,helm3有几大特性:
- 移除了tiller
- 支持分布式helm hub, 有了它就可以在很多时候不需要手动添加非官方repo了,例如helm3 search hub <package name>
- 为chart输入值进行json schema验证。
- 可以给helm charts添加test了,通过helm test <release>就能针对部署的应用跑一些tests。
- 部署的时候release name必须指定了,helm2的时候不指定会自动生成一个。
- 删除的时候不需要--purge了,删了就是删了。
##########################################
彻底删除helm chart
Helm chart不需要了,准备删除,先用的helm delete chartname来删除
Usage:
helm uninstall RELEASE_NAME [...] [flags]
Aliases:
uninstall, del, delete, un
结果删除之后发现之前chart里面services占用的端口并未释放,使用helm list 查看,里面我要删除的那个release找不到了,但是端口还是存在的,其实这个release并未删除。
解决:
彻底删除这个release需要用helm delete --purge chartname
#helm delete --purge chartname
这样才会彻底删除这个,之前使用的端口资源都会释放出来.