從Helm2遷移到 Helm v3 的最佳實踐

在 ，我們依靠   和   來編排我們的系統並保持我們的工作負載執行並保持最新狀態。 我們的 JFrog Cloud 服務最初使用 Helm v2 和   外掛部署以增強安全性，但現在我們已成功將數千個版本遷移到 Helm v3。

 

與許多 SaaS 服務提供商一樣，JFrog Cloud 在不同地區的許多 Kubernetes 叢集中執行，包括 AWS、Azure 和 Google 雲提供商。

 

我們在此過程中學到了一些重要的經驗教訓，很高興與大家分享。

 

為什麼遷移到 Helm v3

Helm v3 的第一個版本於 2019 年 11 月釋出， Helm v2 在一年內仍然有更新版本。 但是隨著 Helm 2.17.0 的最終版本於 2020 年 11 月釋出，Helm v3 現在已經是 Helm 開發者社群支援的唯一標準。

 

，最顯著的是刪除了 Tiller。 這個叢集內的伺服器與 Helm v2 客戶端互動的需要管理員許可權才能執行其職責，這被認為是共享 K8S 叢集中的安全風險。 這可以透過 Tillerless 外掛來克服，但 Helm v3 不再需要這樣做。

 

此外， Helm v3 提供了一些新功能和更高的穩定性。 它現在也是唯一一個會在未來獲得有效性和安全性更新的版本。

 

 

遷移策略

為了更輕鬆地將叢集從 Helm v2 遷移到 v3，Helm 開發人員社群建立了 以與 helm3 客戶端一起使用。 這裡有一篇 Helm 部落格文章 提供了有關如何使用它的一些很好的資訊。

 

安裝外掛很簡單：

$ helm3 plugin install

 

但是您接下來如何執行任務可能會根據您需要遷移的版本數量而有所不同。

 

手動遷移

如果您只需要遷移幾個版本，您可以透過客戶端在命令列上進行一一遷移。

 

首先，您可以使用 helm list 命令列出當前名稱空間的所有已部署或失敗的版本：

 

$ helm2 list

NAME     REVISION UPDATED                  STATUS   CHART            APP VERSION NAMESPACE

postgres 1        Thu Nov 14 15:01:00 2019 DEPLOYED postgresql-7.1.0 11.5.0      postgres

 

然後，您可以透過遷移外掛執行每個命名版本的轉換。 我們建議首先使用 --dry-run 標誌來做一下預演，以確保之後的轉換執行 沒問題 。

 

$ helm3 2to3 convert --dry-run postgres

$ helm3 2to3 convert postgres

 

您可以對所有版本重複此過程，您就完成了！

 

企業級的自動化遷移

 

要將多個 Helm v2 版本遷移到 v3，您需要使用 shell 指令碼自動化該過程。

 

您的指令碼將需要轉換的所有版本的列表。 您可以使用 Helm v2 客戶端生成一個列表，在本例中生成一個名為 release.log 的檔案。

 

$ helm2 tiller run -- helm2 ls --max=0 | sed -n '1!p' | awk 'FNR > 1 { print $1 }' > releases.log

 

對於相對較少的版本（最多約 200 個），這會產生快速的結果。

然而，更多的情況下， Helm 客戶端需要很長時間才能獲取所有版本。

此外，我遇到了 AWS EKS 叢集的 Kubernetes API 限制。

 

JFrog Cloud 服務在每個 Kubernetes 叢集上執行數千個 Helm 版本，因此需要一種替代的、更快的方法。

 

由於所有 Tiller secrets 都被標記了，我們發現我們可以使用 kubectl 命令將它們提取到releases.log 檔案中：

 

$ kubectl -n kube-system get secret -l OWNER=TILLER,STATUS=DEPLOYED | awk 'FNR > 1 { print $1 }' | cut -f1 -d"." > releases.log

 

 

使用我們在 releases.log 中的Helm v2 版本列表，我們可以使用bash 指令碼自動執行遷移步驟：

 

 

#!/bin/bash

# Get releases list

RELEASES=$(cat releases.log )

for r in $RELEASES

do

  echo

  echo "Processing release $r"

  helm3 2to3 convert --tiller-out-cluster --release-versions-max=5 \

      --delete-v2-releases --dry-run 2>&1 | tee -a convert.log

done

 

在此指令碼中，您可能想要或需要更改這些標誌：

 

--tiller-out-cluster 如果你沒有在 Kubenetes 叢集中執行 Tiller，則使用； 如果安裝了 Tiller，則應將其刪除。

--delete-v2-releases 在遷移到 Helm v3 後刪除Helm v2 版本

--dry-run 用於測試遷移指令碼是否工作，不真正執行，執行實際遷移時需要刪除此引數

 

如果您選擇省略標誌 --delete-v2-releases 並保留 Helm 2 版本，您可以稍後使用以下命令清理它們：

 

$ helm3 2to3 cleanup --tiller-out-cluster --releases-cleanup --skip-confirmation

 

該指令碼在檔案 convert.log 中檢視遷移結果，您應該檢視該檔案以瞭解可能遇到的任何遷移問題。

 

在我們遷移 JFrog Cloud 服務時，並非所有版本都在同一  chart 版本上 ——它們使用了首次部署時有效的 charts。 所以一些遷移的舊版本無法使用 Helm v3 升級。

 

問題是一些 Helm v3 標籤和註釋沒有被新增到遷移的 Kubernetes 物件中。 當檢查顯示它們不存在時，透過將它們新增到 Helm 升級步驟很容易解決這個問題：

 

$ kubectl -n ${NAMESPACE} label deployment -l "app.kubernetes.io/instance=${RELEASE}" "app.kubernetes.io/managed-by=Helm"

 

$ kubectl -n ${NAMESPACE} annotate deployment -l "app.kubernetes.io/instance=${RELEASE}" "meta.helm.sh/release-name=${RELEASE}" "meta.helm.sh/release-namespace=${NAMESPACE}"

 

讓我們開心遷移吧 ���

這就是將您的版本遷移到 Helm v3 所需的全部內容！

這個過程很簡單，但請記住，它不一定很快。

當有數千個版本時 ——就像在大多數企業級組織中一樣——遷移過程確實需要時間來完成。

 

使用這些步驟，您可以建立一個自動化工具，幫助您將在 Kubernetes 中執行的大量版本從 Helm v2 遷移到 Helm v3 ，並使您的 Kubernetes 基礎設施保持最新。