怎么一次性完成Helm3遷移

這篇文章主要介紹“怎么一次性完成Helm3遷移”，在日常操作中，相信很多人在怎么一次性完成Helm3遷移問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”怎么一次性完成Helm3遷移”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

下載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兼容。盡管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配置

如果你在諸如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"

到此，關于“怎么一次性完成Helm3遷移”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！