現在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！