2019年,Kubernetes軟件包管理器——Helm發佈了最新版本Helm 3,而且該版本已經stable。Helm 3中的一些關鍵特性咱們在以前的文章中已經介紹過,其中一些功能吸引了許多開發人員。那麼,如今你大概想知道升級/遷移到新版本的Helm是否麻煩。儘管Helm可能十分複雜,可是請不要擔憂,升級過程極爲簡單。Helm官方blog提供了有關遷移過程的指南,十分詳細,歡迎查閱:api
https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/服務器
這篇官方指南十分直觀地告訴你將版本分別遷移到Helm 3所需準備的一切。可是若是你想要一次性完成遷移應該怎麼辦呢?你如何確保在刪除Tiller以前沒有任何組件在使用它oop
咱們測試Helm 2以及最新版本,所以在Helm 2徹底卸載以前,咱們應該準備好兩個版本的二進制文件。下載最新Stable版本的二進制文件並將其添加到你的PATH中。將現有的v2二進制文件重命名爲helm2以及將最新版本重命名爲helm3。我將兩個版本都保存在/usr/local/bin
中,以便我可以隨時切換它們:post
➜ 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是否與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啦!ui
我在文章開頭提到的Helm博客文章中有這一步驟的詳細描述,它將會更新全部你的本地配置以便Helm 3可使用它:插件
https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/#migrate-helm-v2-configuration3d
若是你在諸如Jenkins、TeamCity或TravisCI之類的CI系統中的構建代理運行Helm,那麼能夠這一步驟。若是你在本地機器或有持久文件系統的中央服務器中運行Helm,那麼必定要在整個配置中進行遷移,尤爲是當你擁有本身的Helm repo或使用自定義插件時。不管哪一種方式,請確保你已經通讀了這一部分,以肯定是否與你有關。代理
如今,咱們有幾種方式能夠實現遷移。你能夠遷移特定版本到Helm 3來進行一些測試,具體操做在Helm官方博客中能夠找到。你也能夠選擇遷移許多版本並將它們從Tiller中所有刪除。就我我的而言,我發現一次性遷移全部版本到既定環境中更爲簡單,但須要將發佈數據保留在Tiller中,直到肯定在咱們的環境中沒有一處使用Helm 2爲止。如此,就不會產生盲點,全部東西都使用相同版本的Helm:code
# 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刪除。若是你肯定本身再也不須要任何信息,你能夠執行這一操做,風險自擔。
這一步是我最不想略過的一步,以防萬一咱們須要回滾到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-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"