Helm v2 から v3 への移行

このガイドでは、Helm v2 から v3 への移行方法を説明します。Helm v2 がインストールされ、1つ以上のクラスタでリリースを管理している必要があります。

Helm 3 の変更点の概要

Helm 2 から 3 への変更点の完全なリストは、FAQ セクションに記載されています。以下は、移行前および移行中にユーザーが注意すべき変更点の一部をまとめたものです。

1. Tiller の削除
   • クライアント/サーバーをクライアント/ライブラリのアーキテクチャ（helmバイナリのみ）に置き換えます。
   • セキュリティは、ユーザー単位（Kubernetes ユーザークラスタセキュリティに委任）になりました。
   • リリースはクラスター内のシークレットとして保存されるようになり、リリースオブジェクトのメタデータが変更されました。
   • リリースは、Tiller 名前空間ではなく、リリース名前空間単位で永続化されるようになりました。
2. チャートリポジトリが更新されました。
   • helm search は、ローカルリポジトリ検索と Artifact Hub に対する検索クエリの両方をサポートするようになりました。
3. 以下の仕様変更のため、チャートの apiVersion が "v2" に引き上げられました。
   • 動的にリンクされたチャートの依存関係は、Chart.yaml に移動しました（requirements.yaml は削除され、requirements --> dependencies）。
   • ライブラリチャート（ヘルパー/共通チャート）を、動的にリンクされたチャートの依存関係として追加できるようになりました。
   • チャートには、チャートをapplicationまたはlibraryチャートとして定義するための type メタデータフィールドがあります。デフォルトでは application であり、レンダリング可能でインストール可能であることを意味します。
   • Helm 2 チャート（apiVersion=v1）は、引き続きインストール可能です。
4. XDG ディレクトリ仕様が追加されました。
   • Helm ホームが削除され、構成ファイルを保存するための XDG ディレクトリ仕様に置き換えられました。
   • Helm を初期化する必要がなくなりました。
   • helm init と helm home が削除されました。
5. その他の変更点
   • Helm のインストール/セットアップが簡素化されました。
     • Helm クライアント（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 クラスタを管理できます。
     • クラスタに対して 1つから複数の 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 プラグインの使用例を説明するブログ 投稿