一文教你一次性完成Helm 3遷移
2019年，Kubernetes軟體包管理器——Helm釋出了最新版本Helm 3，並且該版本已經stable。Helm 3中的一些關鍵特性我們在之前的文章中已經介紹過，其中一些功能吸引了許多開發人員。那麼，現在你大概想知道升級/遷移到新版本的Helm是否麻煩。儘管Helm可能十分複雜，但是請不要擔心，升級過程極為簡單。Helm官方blog提供了有關遷移過程的指南，十分詳細，歡迎查閱：
https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/
這篇官方指南十分直觀地告訴你將版本分別遷移到Helm 3所需準備的一切。但是如果你想要一次性完成遷移應該怎麼辦呢？你如何確保在刪除Tiller之前沒有任何元件在使用它
下載Helm 3二進位制檔案
我們測試Helm 2以及最新版本，因此在Helm 2完全解除安裝之前，我們應該準備好兩個版本的二進位制檔案。下載最新Stable版本的二進位制檔案並將其新增到你的PATH中。將現有的v2二進位制檔案重新命名為helm2以及將最新版本重新命名為helm3。我將兩個版本都儲存在/usr/local/bin中，以便我能夠隨時切換它們：
➜ helm2 version Client: &version.Version{SemVer:"v2.16.0", GitCommit:"e13bc94621d4ef666270cfbe734aaabf342a49bb", GitTreeState:"clean"} Server: &version.Version{SemVer:"v2.14.3", GitCommit:"0e7f3b6637f7af8fcfddb3d2941fcc7cbebb0085", GitTreeState:"clean"} ➜ helm3 version version.BuildInfo{Version:"v3.0.1", GitCommit:"7c22ef9ce89e0ebeb7125ba2ebf7d421f3e82ffa", GitTreeState:"clean", GoVersion:"go1.13.4"}
準備CI指令碼和Chart
在你執行升級流程之前，你需要確認你的CI指令碼以及自定義Chart是否與Helm 3相容。我之前寫過一篇文章（https://itnext.io/breaking-changes-in-helm-3-and-how-to-fix-them-39fea23e06ff ），文章中涵蓋了一些需要注意的事情，其中的大部分都能夠輕鬆解決。儘管OpenAPI驗證機制很有趣，但它很有可能讓你措手不及：
➜ helm install prometheus . Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: ValidationError(Deployment.spec.template.spec.containers\[0\].volumeMounts\[0\]): unknown field "defaultMode" in io.k8s.api.core.v1.VolumeMount
一旦你解決了所有這些麻煩的問題，那麼就可以開始遷移到Helm 3啦！
遷移Helm配置
我在文章開頭提到的Helm部落格文章中有這一步驟的詳細描述，它將會更新所有你的本地配置以便Helm 3可以使用它：
https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/#migrate-helm-v2-configuration
如果你在諸如Jenkins、TeamCity或TravisCI之類的CI系統中的構建代理執行Helm，那麼可以這一步驟。如果你在本地機器或有持久檔案系統的中央伺服器中執行Helm，那麼一定要在整個配置中進行遷移，尤其是當你擁有自己的Helm repo或使用自定義外掛時。無論哪種方式，請確保你已經通讀了這一部分，以確定是否與你有關。
遷移版本（保留Tiller）
現在，我們有幾種方式可以實現遷移。你可以遷移特定版本到Helm 3來進行一些測試，具體操作在Helm官方部落格中可以找到。你也可以選擇遷移許多版本並將它們從Tiller中全部刪除。就我個人而言，我發現一次性遷移所有版本到既定環境中更為簡單，但需要將釋出資料保留在Tiller中，直到確定在我們的環境中沒有一處使用Helm 2為止。如此，就不會產生盲點，所有東西都使用相同版本的Helm：
# List Helm 2 Releases
# omit --tls flag if you're not using TLS
RELEASES=$(helm list --tls -aq)
# Loop through releases and, for each one, test conversion
while IFS= read -r release; do
helm3 2to3 convert $release --dry-run
done <<< "$RELEASES"你感到滿意之後，可以刪除--dry-run標誌，並靜觀2to3外掛發揮其作用。
請注意：正如我所提到的，這裡有--delete-v2-releases標誌，它將會遷移版本並從Tiller刪除。如果你確定自己不再需要任何資訊，你可以執行這一操作，風險自擔。
移除Tiller之前……
這一步是我最不想略過的一步，以防萬一我們需要回滾到Helm 2。此時，只要你的CI系統和團隊成員都在使用Helm 3，就沒有理由保留Tiller。但如果你想完全確保沒有任何元件還將會使用舊版本，那我建議你還是將Tiller保留幾個小時並觀察helm ls的輸出結果以檢視UPDATEDcolumn中的時間戳是否完全改變。如果改變了，就意味著有人/有些元件沒有使用Helm 3。
如果將版本遷移到Helm 3之後，由Helm 2對其進行了修改，你將必須刪除儲存了版本資訊的Helm 3 Kubernetes secret，才能夠將其從Helm 3中清除，而不會刪除相關資源：
➜ kubectl get secret -n dev
NAMESPACE NAME TYPE DATA AGE dev sh.helm.release.v1.postgres.v1 helm.sh/release.v1 1 36d
➜ kubectl delete secret -n dev sh.helm.release.v1.postgres.v1
secret "secret "sh.helm.release.v1.postgres.v1" deleted現在如果我們使用Helm 3列出在dev名稱空間中的版本，我們將會看到那些版本已經不復存在：
NAME NAMESPACE REVISION UPDATED
STATUS CHART APP VERSION在我們弄清楚誰依舊在使用Helm 2之後，我們就可以再次執行遷移流程。解決此問題後，請使用helm3 2to3 convert進行遷移。
一旦你完全確定你可以移除Tiller及其相關的RBAC角色和資料，那麼就可以執行 helm 2to3 cleanup。
遷移版本——沒有Tiller的Helm
直接新增--tiller-out-cluster標誌到我在之前提供的指令碼中，然後2to3外掛將從你的本地Tiller例項中移除版本資訊。
# List Helm 2 Releases
# omit --tls flag if you're not using TLS
RELEASES=$(helm list --tls -aq)
# Loop through releases and, for each one, test conversion
while IFS= read -r release; do
helm3 2to3 convert $release --tiller-out-cluster
done <<< "$RELEASES"