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