现在helm基本已经是k8s应用发布的标配了，下面整理了一些小知识
一、v2和v3有什么区别？
1、移除tiller
v2版本： helm通过tiller组件与apiserver去交互的，tiller是需要部署在k8s中的
v3版本： helm直接通过kubeconfig去和apiserver通信了，精简了tiller，稳定性和性能貌似更好了
2、删除一个release的命令改变
v3版本中不需要指定--purge了，默认就自带这个参数了
v2版本： helm delete test_release --purge
v3版本： helm uninstall test_release
3、查看charts信息的命令改变
只是更改了一个单词，结果看起来好像一样
v2版本: helm inspect release-name v3版本: helm show release-name
4、拉取chart包的命令改变
只是改了一个单词，变得和docker类似
v2版本: helm fetch chart-name v3版本: helm pull chart-name
5、可命名相同名称的release
v2版本： release名称具有唯一性，不能存在相同名称的release
v3版本： release名称可以相同，用不同的namespace区分
5、部署release时候需要指定名称
v2版本: 不需要指定
v3版本: helm install test_release ./mychart
6、release信息存储的命名空间改变
v2版本： 存储在tiller命名空间下，所以release名称不能相同
v3版本： 没有tiller，存储在release实例对应的命名空间下，所以在不同命名空间，可能存在相同名称的release
二、使用helm镜像应用升级时，镜像的tag不要用latest
曾经搞过一个第三方的k8s集群,那边规划的应用镜像tag为latest，每次发布的时候会把镜像升级，然后覆盖打上latest标签，然后就开始了入坑之旅
同类应用使用同一模版，用不通的yam来控制变量
1、更新镜像后覆盖latest标签，然后执行应用发布，我这里chart部署是statefulset应用
helm upgrade -f xxx.yaml test_release harbor/mychart -n dev
执行以后，statefulset没什么动静，pod也没有滚动的迹象，k8s竟然没有重新编排！因为helm的配置并没有改动，如果镜像拉取规则是Always，手动进行滚动可以实现，如果是IfNotPresent，那么此方法不能进行升级，且容易受到本地的镜像伪装攻击。
2、尝试加入--set image.tag=latest
helm upgrade -f xxx.yaml --set image.tag=latest test_release harbor/mychart -n dev
奇怪的事情来了，执行以后只会升级标识为0的pod，即使我重新设置了滚动更新策略
updateStrategy: type: RollingUpdate rollingUpdate: partition: 0
最后效果并不管用，k8s编排完全无视了我的这个设置，所以还是无法正常的发布应用的。
3、尝试加入 --set image.tag=2021-04-25-12-00-00 (随便设置了个时间戳)
helm upgrade -f xxx.yaml --set image.tag=2021-04-25-12-00-00 test_release harbor/mychart -n dev
发现应用可以正常滚动升级
建议使用helm进行应用发布时，镜像版本千万不要用latest！