從 Helm v2 遷移至 v3

本指南說明如何將 Helm v2 移轉至 v3。必須安裝 Helm v2 並在一個或多個叢集中管理發佈。

Helm 3 變更概述

從 Helm 2 到 3 的完整變更清單記載於 常見問題解答部分。以下是幾項在移轉期間和移轉前應知悉的變更摘要

1. 移除 Tiller
   • 將客戶端/伺服器改為客戶端/套件庫架構（僅 helm 執行檔）
   • 安全性現在以每使用者為基礎（委派給 Kubernetes 使用者叢集安全性）
   • 發佈現在儲存在叢集內秘密中，而且發佈物件的元資料已變更
   • 發佈持續在發佈名稱空間基礎上，不再在 Tiller 名稱空間中
2. 更新圖表存放庫
   • helm search 現在支援在本地存放庫中搜尋和針對 Artifact Hub 進行搜尋查詢
3. 因應以下規格變更，將圖表 API 版本升級到「v2」
   • 動態連結的圖表相依性移至 Chart.yaml（已移除 requirements.yaml 和 requirements → dependencies）
   • 現在可以將套件庫圖表（幫助程式/共用圖表）新增為動態連結的圖表相依性
   • 圖表具有 type 元資料欄位來定義圖表為 application 或 library 圖表。預設為應用程式，意即它可提供而且可安裝
   • Helm 2 圖表（apiVersion=v1）仍可安裝
4. 新增 XDG 目錄規格
   • 已移除 Helm 首頁並以 XDG 目錄規格取代，以儲存組態檔
   • 不再需要初始化 Helm
   • 已移除 helm init 和 helm home
5. 其他變更
   • Helm 安裝/設定已簡化
     • 僅 Helm Client（helm 執行檔）（無 Tiller）
     • 原樣執行模式
   • 預設不設定 local 或 stable 存放庫
   • 已移除 crd-install 掛鉤，並在圖表中的 crds 目錄取代該掛鉤，該目錄中定義的 CRD 將在對圖表進行任何提供之前安裝
   • test-failure鉤子註解值已移除，而test-success已棄用。請使用test
   • 指令已移除/已取代/已新增
     • delete --> uninstall：預設移除所有發佈記錄（以前需要--purge）
     • fetch --> pull
     • home（已移除）
     • init（已移除）
     • install：需要發佈名稱或--generate-name參數
     • inspect --> show
     • reset（已移除）
     • serve（已移除）
     • template：-x/--execute參數更名為-s/--show-only
     • upgrade：新增參數--history-max，限制每個版本儲存的最高修訂號碼（0為無限制）
   • Helm 3 Go 函式庫經歷許多變更，與 Helm 2 函式庫不相容
   • 發佈二進位檔現由get.helm.sh主機

移轉使用案例

移轉使用案例如下

1. Helm v2 和 v3 管理相同的叢集

   • 僅在您打算逐步淘汰 Helm v2，且不需要 v3 管理 v2 部署的任何發佈時，才建議使用此使用案例。應由 v3 部署所有新部署的發佈，而現有的 v2 已部署發佈應僅由 v2 更新/移除
   • Helm v2 和 v3 可以很順利地管理相同的叢集。Helm 版本可以安裝在相同或不同的系統上
   • 如果在相同的系統上安裝 Helm v3，您需要執行額外步驟，以確保兩個用戶端版本可以在準備移除 Helm v2 用戶端之前並存。重新命名或將 Helm v3 二進位檔放在不同的資料夾中，以避免衝突
   • 否則，兩個版本之間不會有衝突，因為有以下區別
     • v2 和 v3 發佈（記錄）儲存彼此獨立。這些變更包括用於儲存和儲存在資源中的發佈物件中繼資料的 Kubernetes 資源。發佈也將位於每個使用者命名空間，而不是使用 Tiller 命名空間（例如，v2 預設 Tiller 命名空間 kube-system）。v2 使用 Tiller 命名空間和TILLER擁有權下的「ConfigMaps」或「Secrets」。v3 使用使用者命名空間和helm擁有權下的「Secrets」。發佈在 v2 和 v3 中都具增量性
     • 唯一的問題可能是如果 Kubernetes 叢集範圍資源（例如，clusterroles.rbac）定義在圖表中。v3 部署將隨之失敗，即使在命名空間中唯一，因為資源會衝突
     • v3 組態不再使用$HELM_HOME，而是改用 XDG 目錄規格。它也會在需要時動態建立。因此，它與 v2 組態無關。這僅適用於在相同的系統上安裝兩個版本的狀況

2. 將 Helm v2 移轉至 Helm v3

   • 當您想要讓 Helm v3 管理現有的 Helm v2 發佈時，適用此使用案例
   • 請注意，Helm v2 用戶端
     • 可以管理 1 到多個 Kubernetes 叢集
     • 可以連線到一個或多個叢集的 Tiller 執行個體
   • 這表示您在將發佈套件部署到群集和它自己的命名空間的時候，必須瞭解 Tiller 和它的命名空間會有的狀況。因此您必須知道如何針對每個群集和 Helm v2 應用程式執行個體管理的 Tiller 個體進行移轉
   • 建議的資料移轉路徑如下
     1. 備份 v2 資料
     2. 移轉 Helm v2 組態
     3. 移轉 Helm v2 發佈套件
     4. 當您確信 Helm v3 能夠管理所有 Helm v2 資料（針對 Helm v2 應用程式執行個體的所有群集和 Tiller 個體），然後清除 Helm v2 資料
   • 此移轉流程是由 Helm v3 2to3 外掛程式自動化

參考

• Helm v3 2to3 外掛程式
• 部落格 貼文說明 2to3 外掛程式的用法及範例