29 ダウンストリームクラスタ #

このセクションでは、管理クラスタを使用して、ダウンストリームクラスタのさまざまな部分に対して、各種のDay 2操作を行う方法について説明します。

29.1 はじめに #

このセクションは、Day 2操作に関するドキュメントの「出発点」となることを目的としています。次の情報を確認できます。

複数のダウンストリームクラスタでDay 2操作を実行するために使用するデフォルトコンポーネント(29.1.1項「コンポーネント」)。
自身の特定のユースケース(29.1.2項「ユースケースの決定」)にどのDay 2リソースを使用するかの判断。
Day 2操作に推奨されるワークフローシーケンス(29.1.3項「Day 2ワークフロー」)。

29.1.1 コンポーネント #

以下に、Day 2操作を正常に実行できるように、 管理クラスタまたは ダウンストリームクラスタのいずれかでセットアップする必要があるデフォルトコンポーネントについて説明します。

29.1.1.1 Rancher #

注記

RancherなしでFleet (第6章「Fleet」)を利用するユースケースの場合、Rancherコンポーネントを完全にスキップできます。

ダウンストリームクラスタの管理を担当します。管理クラスタ上にデプロイする必要があります。

詳細については、第4章「Rancher」を参照してください。

29.1.1.2 Fleet #

マルチクラスタリソースのデプロイメントを担当します。

通常は、Rancherコンポーネントによって提供されます。 Rancherを使用しないユースケースでは、スタンドアロンコンポーネントとしてデプロイできます。

Fleetをスタンドアロンコンポーネントとしてインストールする方法の詳細については、Fleetのインストールの詳細を参照してください。

Fleetコンポーネントに関する詳細については、第6章「Fleet」を参照してください。

重要

このドキュメントは、GitOps方式でDay 2操作に関連するリソースのデプロイメントを自動化するために、Fleet、具体的にはGitRepoとBundleリソース(この詳細は29.1.2項「ユースケースの決定」で詳しく説明します)に大きく依存しています。

サードパーティのGitOpsツールの使用が必要なユースケースの場合は、以下を参照してください。

OSアップグレードの場合 - 29.2.4.3項「SUC Planのデプロイメント - サードパーティのGitOpsワークフロー」
Kubernetesディストリビューションの更新の場合 - 29.3.4.3項「SUC Planのデプロイメント - サードパーティのGitOpsワークフロー」
EIBでデプロイされたHelmチャートのアップグレードの場合 - 29.4.3.3.4項「サードパーティのGitOpsツールを使用したHelmチャートのアップグレード」
EIB以外でデプロイされたHelmチャートのアップグレードの場合 - 45.1項「要約」ページから目的のEdgeリリースによってサポートされているチャートバージョンを取得し、サードパーティのGitOpsツールにチャートバージョンとURLを入力します

29.1.1.3 System Upgrade Controller (SUC) #

System Upgrade Controller (SUC)は、 Planと呼ばれるカスタムリソースを通じて提供される設定データに基づいて指定されたノードでタスクを実行する責任を負います。

注記

SUCで異なるDay 2操作をサポートできるようにするには、SUCがアップグレードを必要とする各ダウンストリームクラスタにデプロイされることが重要です。

SUCコンポーネントとそれがEdgeスタックにどのように適合するかに関する詳細については、System Upgrade Controller (第19章「System Upgrade Controller」)コンポーネントのドキュメントを参照してください。

ダウンストリームクラスタにSUCをデプロイする方法については、まず、ユースケース(29.1.2項「ユースケースの決定」)を決定してから、「System Upgrade Controllerのインストール - GitRepo」(19.2.1.1項「System Upgrade Controllerのインストール - GitRepo」)または「System Upgrade Controllerのインストール - バンドル」(19.2.1.2項「System Upgrade Controllerのインストール - バンドル」)を参照してください。

29.1.2 ユースケースの決定 #

前述のように、Day 2操作に関連するリソースは、FleetのGitRepoリソースとBundleリソースを使用してダウンストリームクラスタに伝播されます。

以下に、これらのリソースの機能と、 Day 2操作に使用する必要があるユースケースに関する詳細を説明します。

29.1.2.1 GitRepo #

GitRepoは、Fleetがバンドルの作成元として使用できるGitリポジトリを表すFleet (第6章「Fleet」)リソースです。各バンドルは、GitRepoリソースの内部で定義された設定パスに基づいて作成されます。詳細については、GitRepoのドキュメントを参照してください。

Day 2操作に関して、GitRepoリソースは通常、Fleet GitOps アプローチを利用する非エアギャップ環境へのSUCまたはSUC Planのデプロイに使用されます。

または、リポジトリのセットアップをローカルGitサーバ経由でミラーリングすると、GitRepoリソースを使用して、SUCまたはSUC Planをエアギャップ環境にデプロイすることもできます。

29.1.2.2 バンドル #

バンドルは、ターゲットクラスタにデプロイする 「生」のKubernetesリソースを保持します。バンドルは通常、GitRepoリソースから作成されますが、手動でデプロイできるユースケースもあります。詳細については、バンドルのドキュメントを参照してください。

Day 2操作の観点では、バンドルリソースは通常、何らかの形態のローカルGitOps手法を使用しないエアギャップ環境(「ローカルGitサーバ」など )でSUCまたはSUC Planをデプロイするために使用されます。

または、ご自身のユースケースでGitOpsワークフローを使用できない場合は(Gitリポジトリを使用する場合など)、バンドルリソースを使用して、SUCまたはSUC Planを非エアギャップ環境にデプロイすることもできます。

29.1.3 Day 2ワークフロー #

以下に、ダウンストリームクラスタを特定のEdgeリリースにアップグレードする際に従う必要があるDay 2ワークフローを示します。

OSアップグレード(29.2項「OSのアップグレード」)
Kubernetesバージョンアップグレード(29.3項「Kubernetesバージョンアップグレード」)
Helmチャートのアップグレード(29.4項「Helmチャートのアップグレード」)

29.2 OSのアップグレード #

29.2.1 コンポーネント #

このセクションでは、 OSアップグレードプロセスがデフォルトのDay 2コンポーネント(29.1.1項「コンポーネント」)よりも使用するカスタムコンポーネントについて説明します。

29.2.1.1 systemd.service #

あるEdgeバージョンから別のEdgeバージョンにOSが必要とするアップグレードに応じて、異なるsystemd.serviceが作成されます。

同じ OS バージョン(例: 6.0)を必要とするEdgeバージョンの場合、os-pkg-update.serviceが作成されます。これはtransactional-updateコマンドを使用して、通常のパッケージアップグレードを実行します。
OSバージョンのマイグレーションが必要なEdgeバージョンの場合(例5.5 → 6.0)、os-migration.serviceが作成されます。これはtransactional-updateを使用して以下を実行します。
- まず、通常のパッケージアップグレードを実行します。マイグレーション前にすべてのパッケージが最新バージョンであることを確認するために行われます。古いパッケージバージョンに関連する障害を軽減します。
- その後、 zypper migrationコマンドを利用して、OSマイグレーションプロセスを続行します。

OSアップグレードが必要が各 ダウンストリームクラスタに配置されているSUC Plan通じて配布されます。

29.2.2 要件 #

全般:

SCC登録マシン - すべてのダウンストリームクラスタをhttps://scc.suse.com/に登録する必要があります。これは、os-pkg-update.service/os-migration.serviceが必要なOS RPMリポジトリに正常に接続できるようにするために必要です。
重要
新しいOSバージョン(例: Edge 3.1)を必要とするEdgeリリースの場合、SCCキーが新しいバージョンへのマイグレーションをサポートしていることを確認します(例: Edge 3.1の場合は、SCCキーがSLE Micro 5.5 → 6.0へのマイグレーションをサポートしている必要があります)。
SUC PlanのTolerationがノードのTolerationと一致すること - KubernetesクラスタノードにカスタムのTaintが設定されている場合は、SUC PlanにそのTaintに対するTolerationを追加してください。デフォルトでは、SUC Planには、control-planeノードのTolerationのみが含まれます。デフォルトのTolerationは次のとおりです。
- CriticalAddonsOnly=true:NoExecute
- node-role.kubernetes.io/control-plane:NoSchedule
- node-role.kubernetes.io/etcd:NoExecute
  注記
  追加のTolerationは、各Planの .spec.tolerationsセクションに追加する必要があります。OSアップグレードに関連するSUC Planは、fleets/day2/system-upgrade-controller-plans/os-upgradeの下のsuse-edge/fleet-examplesリポジトリにあります。有効なリポジトリリリースreleaseタグからのPlanを使用してください。
  control-plane SUC Planに対してカスタムのTolerationを定義する例は次のようになります。
  apiVersion: upgrade.cattle.io/v1 kind: Plan metadata: name: os-upgrade-control-plane spec: ... tolerations: # default tolerations - key: "CriticalAddonsOnly" operator: "Equal" value: "true" effect: "NoExecute" - key: "node-role.kubernetes.io/control-plane" operator: "Equal" effect: "NoSchedule" - key: "node-role.kubernetes.io/etcd" operator: "Equal" effect: "NoExecute" # custom toleration - key: "foo" operator: "Equal" value: "bar" effect: "NoSchedule" ...

エアギャップ:

SUSE RPMリポジトリのミラーリング - OS RPMリポジトリをローカルにミラーリングし、os-pkg-update.service/os-migration.serviceそのリポジトリにアクセスできるようにする必要があります。このためには、RMTまたはSUMAのいずれかを使用します。

29.2.3 更新手順 #

注記

このセクションは、Fleet (第6章「Fleet」)を使用してOSアップグレード SUC Plan をデプロイすることを前提としています。異なる方法でSUC Planをデプロイする場合は、 29.2.4.3項「SUC Planのデプロイメント - サードパーティのGitOpsワークフロー」を参照してください。

重要

この手順を使用して以前にアップグレードした環境の場合、ユーザは次の手順のいずれかを完了していることを確認する必要があります。

ダウンストリームクラスタから古いEdgeリリースバージョンに関連する以前にデプロイしたSUC Planを削除する - これは、既存のGitRepo/Bundleターゲット設定から目的のダウンストリームクラスタを削除するか、GitRepo/バンドルリソースを完全に削除することで、実行できます。
既存のGitRepo/バンドルリソースを再利用する - 目的のsuse-edge/fleet-examples リリースの正しいフリートを保持する新しいタグにリソースのリビジョンをポイントすることで実行できます。

これは古いEdgeリリースバージョンのSUC Plan間のクラッシュを回避するために実行されます。

ユーザがアップグレードを試す場合、ダウンストリームクラスタに既存のSUC Planがある場合は、次のフリートエラーが表示されます。

Not installed: Unable to continue with install: Plan <plan_name> in namespace <plan_namespace> exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error..

OSアップグレード手順は、 SUC Planをダウンストリームクラスタにデプロイする手順が中心になります。その後、これらのPlanには、os-pkg-update.service/os-migration.serviceをどのような方法でどのノードにデプロイするかに関する情報が保持されます。SUC Planの構造の詳細については、アップストリームドキュメントを参照してください。

OS アップグレードSUC Planは次の方法で配布されます。

GitRepoリソースを通じて - 29.2.4.1項「SUC Planのデプロイメント - GitRepoリソース」
バンドルリソースを通じて - 29.2.4.2項「SUC Planのデプロイメント - バンドルリソース」

どのリソースを使用すべきかを判断するには、29.1.2項「ユースケースの決定」を参照してください。

アップグレード手順の完全な概要については、29.2.3.1項「概要」セクションを参照してください。

29.2.3.1 概要 #

このセクションは、OSアップグレードプロセスが最初から最後まで通過する完全なワークフローを説明することを目的としています。

図 29.1: OSアップグレードのワークフロー #

OSアップグレード手順:

ユースケースに基づいて、ユーザは目的のダウンストリームクラスタへのOSアップグレードSUC Planのデプロイメントに対して、GitRepoリソースまたはバンドルリソースのどちらを使用するかどうかを決定します。GitRepo/バンドルを特定のダウンストリームクラスタのセットにマッピングする方法については、「Mapping to Downstream Cluster (ダウンストリームクラスタへのマッピング)」を参照してください。
1. SUC PlanのデプロイメントにGitRepoリソースまたはバンドルリソースのどちらを使用すべきかわからない場合は、29.1.2項「ユースケースの決定」を参照してください。
2. GitRepo/バンドル設定オプションについては、29.2.4.1項「SUC Planのデプロイメント - GitRepoリソース」または29.2.4.2項「SUC Planのデプロイメント - バンドルリソース」を参照してください。
ユーザは設定済みのGitRepo/バンドルリソースを自身の管理クラスタのfleet-defaultネームスペースにデプロイします。これは、手動または使用可能な場合はRancher UIから実行できます。
Fleet (第6章「Fleet」)は、fleet-defaultネームスペースを絶えず監視し、新しくデプロイされたGitRepo/バンドルリソースをすぐに検出します。Fleetが監視するネームスペースの詳細については、Fleetの「Namespaces (ネームスペース)」のドキュメントを参照してください。
ユーザがGitRepoリソースをデプロイした場合、Fleetは、GitRepoを調整し、そのパスとfleet.yamlの設定に基づいて、バンドルリソースをfleet-defaultネームスペースにデプロイします。詳細については、Fleetの「Git Repository Contents (Gitリポジトリの内容)」のドキュメントを参照してください。
Fleetは、続いてKubernetesリソースをこのバンドルから、ターゲットとするすべての ダウンストリームクラスタにデプロイします。OSアップグレードのコンテキストでは、Fleetは、次のリソースをバンドルからデプロイします。
1. ワーカーSUC Plan - クラスタのワーカーノードでOSアップグレードを行う方法についてSUCに指示します。クラスタがコントロールプレーンノードのみで構成されている場合、これは解釈 「されません」。すべてのコントロールプレーンSUC Planが正常に完了した後で実行されます。
2. コントロールプレーンSUC Plan - クラスタコントロールプレーンノードでOSアップグレードを実行する方法についてSUCに指示します。
3. スクリプトシークレット - 各 SUC Planで参照されます。実際のOSアップグレードを実行するos-pkg-update.service/os-migration.serviceの作成を担当するupgrade.shスクリプトが配布されます。
4. スクリプトデータConfigMap - 各SUC Planで参照されます。upgrade.shスクリプトで使用される設定が配布されます。
  注記
  上記のリソースは、各ダウンストリームクラスタのcattle-systemネームスペースにデプロイされます。
ダウンストリームクラスタで、SUCは、新しくデプロイされたSUC Planを検出し、SUC Planで定義されたノードセレクタと一致する各ノードに更新Podをデプロイします。SUC Plan Podを監視する方法については、 19.3項「System Upgrade Controller Planのモニタリング」を参照してください。
更新Pod (各ノードにデプロイ)は、スクリプトシークレットをマウントし、シークレットによって配布されるupgrade.shスクリプトを実行します。
upgrade.shは次の処理を続行します。
1. その設定に基づいて、OSがパッケージ更新を必要としているか、移行する必要があるかどうかを決定します。
2. 上記の結果に基づいて、os-pkg-update.service (パッケージ更新用)、または os-migration.service (マイグレーション用)のいずれかを作成します。サービスは oneshotタイプであり、次のワークフローを採用します。
  1. os-pkg-update.serviceの場合:
    transactional-update cleanup upを実行して、ノードOS上のすべてのパッケージバージョンを更新します。
    transactional-updateが成功したら、パッケージバージョンの更新が有効になるように、システムの再起動をスケジュールします。
  2. os-migration.serviceの場合:
    transactional-update cleanup upを実行して、ノードOS上のすべてのパッケージバージョンを更新します。これは、古いパッケージバージョンによってOSマイグレーションエラーが発生しないようにするために実行されます。
    OSを目的の値に移行します。マイグレーションはzypper migrationコマンドを使用して実行されます。
    マイグレーションが有効になるように、システムの再起動をスケジュールします。
3. os-pkg-update.service/os-migration.serviceを開始し、それが完了するまで待ちます。
4. systemd.serviceがそのジョブを実行した後で、os-pkg-update.service/os-migration.serviceをクリーンアップします。今後、誤って実行/再起動されることがないように、システムから削除されます。

OSアップグレード手順は、システムの再起動で終了します。再起動後、OSパッケージバージョンはアップグレードされ、Edgeリリースが必要な場合は、OSも同様に移行される場合があります。

29.2.4 OSアップグレード - SUC Planのデプロイメント #

このセクションでは、Fleetの GitRepoおよび バンドルリソースを使用した SUC Plan関連のOSアップグレードのデプロイメントをオーケストレーションする方法について説明します。

29.2.4.1 SUC Planのデプロイメント - GitRepoリソース #

必要なOSアップグレード SUC Planを配布する、GitRepoリソースは、次の方法のいずれかでデプロイできます。

Rancher UIを通じて - 29.2.4.1.1項「GitRepoの作成 - Rancher UI」 (Rancherが利用可能な場合)。
(29.2.4.1.2項「GitRepoの作成 - 手動」)リソースを管理クラスタに手動でデプロイする。

デプロイ後に、ターゲットクラスタのノードのOSアップグレードプロセスを監視するには、19.3項「System Upgrade Controller Planのモニタリング」のドキュメントを参照してください。

29.2.4.1.1 GitRepoの作成 - Rancher UI #

Rancher UIを通じてGitRepoリソースを作成するには、公式のドキュメントに従ってください。

Edgeチームは、ユーザがGitRepoリソースのパスとして追加できるすぐに使用できるフリートを維持しています。

重要

常に、このフリートは有効なEdge リリースタグから使用してください。

フリートが配布するSUC planにカスタム許容値を含める必要がないユースケースでは、ユーザはsuse-edge/fleet-examplesリポジトリから os-upgradeフリートを直接参照できます。

カスタム許容値が必要な場合、ユーザは別のリポジトリからos-upgradeフリートを参照して、必要に応じてSUC Planに許容値を追加できます。

GitRepoをsuse-edge/fleet-examplesリポジトリのフリートを使用するように設定する方法の例については、こちらを参照してください。

29.2.4.1.2 GitRepoの作成 - 手動 #

GitRepoリソースをプルします。

curl -o os-upgrade-gitrepo.yaml https://raw.githubusercontent.com/suse-edge/fleet-examples/refs/tags/release-3.1.2/gitrepos/day2/os-upgrade-gitrepo.yaml

GitRepo設定を編集し、spec.targetsで目的のターゲットリストを指定します。デフォルトでは、suse-edge/fleet-examplesのGitRepoリソースはどのダウンストリームクラスタにもマップ「されません」。
- すべてのクラスタ変更に一致させるには、デフォルトのGitRepoターゲットを次のように変更します。
```
spec:
  targets:
  - clusterSelector: {}
```
- または、クラスタをより細かく選択したい場合は、「Mapping to Downstream Cluster (ダウンストリームクラスタへのマップ)」を参照してください
GitRepoリソースを管理クラスタに適用します。
```
kubectl apply -f os-upgrade-gitrepo.yaml
```

fleet-defaultネームスペースで、作成した GitRepoリソースを表示します。

kubectl get gitrepo os-upgrade -n fleet-default

# Example output
NAME            REPO                                              COMMIT         BUNDLEDEPLOYMENTS-READY   STATUS
os-upgrade      https://github.com/suse-edge/fleet-examples.git   release-3.1.2  0/0

29.2.4.2 SUC Planのデプロイメント - バンドルリソース #

必要な OSアップグレード SUC Planを配布する、 バンドルリソースは次の方法のいずれかでデプロイできます。

Rancher UIを通じて - 29.2.4.2.1項「バンドルの作成 - Rancher UI」 (Rancherが利用可能な場合)。
(29.2.4.2.2項「バンドルの作成 - 手動」)リソースを管理クラスタに手動でデプロイする。

29.2.4.2.1 バンドルの作成 - Rancher UI #

Edgeチームは、以下の手順で使用可能なすぐに使用できるバンドルを維持しています。

重要

このバンドルは常に有効なEdgeリリースタグから使用してください。

RancherのUIを通じてバンドルを作成するには、次の手順に従います。

左上隅で、［☰］ → ［Continuous Delivery (継続的デリバリ)］をクリックします。
［Advanced (詳細)］>［Bundles (バンドル)］ に移動します。
［Create from YAML (YAMLから作成)］を選択します。
ここから次のいずれかの方法でバンドルを作成できます。
注記
バンドルが配布する SUC planにカスタム許容値を含める必要があるユースケースがある場合があります。以下の手順で生成されるバンドルには、必ずこれらの許容値を含めるようにします。
1. バンドルコンテンツをsuse-edge/fleet-examplesから［Create from YAML (YAMLから作成)］ページに手動でコピーする。
2. 目的のリリースタグからsuse-edge/fleet-examplesのクローンを作成し、［Create from YAML (YAMLから作成)］ページの［Read from File (ファイルから読み取り)］オプションを選択する。ここからバンドルの場所(bundles/day2/system-upgrade-controller-plans/os-upgrade)に移動して、バンドルファイルを選択できます。これにより、バンドルコンテンツを持つ［Create from YAML (YAMLから作成)］ページが自動入力されます。
バンドルのターゲットクラスタを次のように変更します。
- すべてのダウンストリームクラスタに一致させるには、デフォルトのバンドル.spec.targetsを次のように変更します。
```
spec:
  targets:
  - clusterSelector: {}
```
- より細かくダウンストリームクラスタにマッピングするには、「Mapping to Downstream Clusters (ダウンストリームクラスタへのマップ)」を参照してください。
［Create (作成)］を選択します。

29.2.4.2.2 バンドルの作成 - 手動 #

バンドルリソースをプルします。

curl -o os-upgrade-bundle.yaml https://raw.githubusercontent.com/suse-edge/fleet-examples/refs/tags/release-3.1.2/bundles/day2/system-upgrade-controller-plans/os-upgrade/os-upgrade-bundle.yaml

バンドルのターゲット設定を編集し、spec.targetsに目的のターゲットリストを指定します。デフォルトでは、suse-edge/fleet-examplesのバンドルリソースは、どのダウンストリームクラスタにもマップ「されません」。
- すべてのクラスタに一致させるには、デフォルトのバンドルのターゲットを次のように変更します。
```
spec:
  targets:
  - clusterSelector: {}
```
- または、クラスタをより細かく選択したい場合は、「Mapping to Downstream Cluster (ダウンストリームクラスタへのマップ)」を参照してください
バンドルリソースを管理クラスタに適用します。
```
kubectl apply -f os-upgrade-bundle.yaml
```
fleet-defaultネームスペースで、作成したバンドルリソースを表示します。
```
kubectl get bundles -n fleet-default
```

29.2.4.3 SUC Planのデプロイメント - サードパーティのGitOpsワークフロー #

ユーザがOSアップグレードSUC Planを独自のサードパーティGitOpsワークフロー(例: Flux)に組み込むユースケースがある場合があります。

必要なOSアップグレードリソースを取得するには、まず使用するsuse-edge/fleet-examplesリポジトリのEdge リリースタグを決定します。

その後、リソースはfleets/day2/system-upgrade-controller-plans/os-upgradeで見つかります。ここでは次のようになります。

plan-control-plane.yaml - コントロールプレーンノードのsystem-upgrade-controller Planリソース。
plan-worker.yaml - ワーカーノードのsystem-upgrade-controller Planリソース。
secret.yaml - upgrade.shスクリプトを配布するシークレット。
config-map.yaml - upgrade.shスクリプトによって使用されるアップグレード設定を提供するConfigMap。

重要

これらのPlanリソースは、system-upgrade-controllerによって解釈され、アップグレードする各ダウンストリームクラスタにデプロイする必要があります。system-upgrade-controllerをデプロイする方法については、19.2項「System Upgrade Controllerのインストール」を参照してください。

GitOpsワークフローをOSアップグレードの SUC Planをデプロイするために使用する方法をよりよく理解するために、Fleetを使用して更新手順の概要(29.2.3.1項「概要」)を確認すると役立つ場合があります。

29.3 Kubernetesバージョンアップグレード #

重要

このセクションでは、Rancher (第4章「Rancher」)インスタンスを使用して作成されて「いない」ダウンストリームクラスタのアップグレードについて説明します。Rancherで作成したクラスタのKubernetesバージョンをアップグレードする方法については、「Upgrading and Rolling Back Kubernetes (Kubernetesのアップグレードとロールバック)」を参照してください。

29.3.1 コンポーネント #

このセクションでは、KubernetesアップグレードプロセスがデフォルトのDay 2コンポーネント(29.1.1項「コンポーネント」)よりも優先して使用するカスタムコンポーネントについて説明します。

29.3.1.1 rke2-upgrade #

特定ノードのRKE2バージョンのアップグレードを行うイメージです。

SUC Planに基づいてSUCによって作成されたPodを通じて配布されます。このPlanは、RKE2のアップグレードが必要な各ダウンストリームクラスタに配置する必要があります。

rke2-upgradeイメージによるアップグレードの実行方法の詳細については、アップストリームドキュメントを参照してください。

29.3.1.2 k3s-upgrade #

特定のノードのK3sバージョンをアップグレードするイメージです。

SUC Planに基づいてSUCによって作成されたPodを通じて配布されます。このPlanは、K3sのアップグレードが必要な各ダウンストリームクラスタに配置する必要があります。

k3s-upgradeイメージによるアップグレードの実行方法の詳細については、アップストリームドキュメントを参照してください。

29.3.2 要件 #

Kubernetesディストリビューションをバックアップします。
1. インポートしたRKE2クラスタについては、RKE2のバックアップと復元に関するドキュメントを参照してください。
2. インポートしたK3sクラスタについては、K3sのバックアップと復元に関するドキュメントを参照してください。
SUC PlanのTolerationがノードのTolerationと一致すること - KubernetesクラスタノードにカスタムのTaintが設定されている場合は、SUC PlanにそのTaintに対するTolerationを追加してください。デフォルトでは、SUC Planには、control-planeノードのTolerationのみが含まれます。デフォルトのTolerationは次のとおりです。
- CriticalAddonsOnly=true:NoExecute
- node-role.kubernetes.io/control-plane:NoSchedule
- node-role.kubernetes.io/etcd:NoExecute
  注記
  追加のTolerationは、各Planの.spec.tolerationsセクションに追加する必要があります。Kubernetesバージョンアップグレードに関するSUC Planは、次の場所のsuse-edge/fleet-examplesリポジトリにあります。
  RKE2 - fleets/day2/system-upgrade-controller-plans/rke2-upgrade
  K3s - fleets/day2/system-upgrade-controller-plans/k3s-upgrade
  必ず、有効なリポジトリリリースタグからのPlanを使用してください。
  RKE2 control-plane SUC PlanのカスタムTolerationの定義例は次のようになります。
  apiVersion: upgrade.cattle.io/v1 kind: Plan metadata: name: rke2-upgrade-control-plane spec: ... tolerations: # default tolerations - key: "CriticalAddonsOnly" operator: "Equal" value: "true" effect: "NoExecute" - key: "node-role.kubernetes.io/control-plane" operator: "Equal" effect: "NoSchedule" - key: "node-role.kubernetes.io/etcd" operator: "Equal" effect: "NoExecute" # custom toleration - key: "foo" operator: "Equal" value: "bar" effect: "NoSchedule" ...

29.3.3 アップグレード手順 #

注記

このセクションでは、SUC PlanをFleet (第6章「Fleet」)を使用してデプロイすることを想定しています。別の方法でSUC Planをデプロイする場合は、29.3.4.3項「SUC Planのデプロイメント - サードパーティのGitOpsワークフロー」を参照してください。

重要

この手順を使用して以前にアップグレードした環境の場合、ユーザは次の手順のいずれかを完了していることを確認する必要があります。

ダウンストリームクラスタから古いEdgeリリースバージョンに関連する以前にデプロイしたSUC Planを削除する - これは、既存のGitRepo/Bundleターゲット設定から目的のダウンストリームクラスタを削除するか、GitRepo/バンドルリソースを完全に削除することで、実行できます。
既存のGitRepo/バンドルリソースを再利用する - 目的のsuse-edge/fleet-examples リリースの正しいフリートを保持する新しいタグにリソースのリビジョンをポイントすることで実行できます。

これは古いEdgeリリースバージョンのSUC Plan間のクラッシュを回避するために実行されます。

ユーザがアップグレードを試す場合、ダウンストリームクラスタに既存のSUC Planがある場合は、次のフリートエラーが表示されます。

Not installed: Unable to continue with install: Plan <plan_name> in namespace <plan_namespace> exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error..

Kubernetesバージョンアップグレード手順は、SUC Planをダウンストリームクラスタにデプロイする手順が中心になります。その後、これらのPlanには、SUCに対し、rke2/k3s-upgradeイメージを実行するPodをどのノード上に作成するかを指示する情報が保持されます。SUC Planの構造については、アップストリームドキュメントを参照してください。

KubernetesアップグレードPlanは次のように配布されます。

GitRepoリソースを使用する - 29.3.4.1項「SUC Planのデプロイメント - GitRepoリソース」
バンドルリソースを使用する - 29.3.4.2項「SUC Planのデプロイメント - バンドルリソース」

どのリソースを使用すべきかを判断するには、29.1.2項「ユースケースの決定」を参照してください。

更新手順中の処理の概要については、29.3.3.1項「概要」のセクションを参照してください。

29.3.3.1 概要 #

このセクションでは、 Kubernetesバージョンのアップグレードプロセスが最初から最後まで通過する完全なワークフローを説明することを目的としています。

図 29.2: Kubernetesバージョンアップグレードのワークフロー #

Kubernetesバージョンアップグレードの手順:

ユーザは、KubernetesアップグレードSUC Planを目的のダウンストリームクラスタにデプロイするために、GitRepoリソースを使用するか、それともバンドルリソースを使用するかをそのユースケースに基づいて判断します。GitRepo/バンドルを特定のダウンストリームクラスタセットにマップする方法の詳細については、「Mapping to Downstream Cluster (ダウンストリームクラスタへのマップ)」を参照してください。
1. SUC PlanのデプロイメントにGitRepoリソースまたはバンドルリソースのどちらを使用すべきかわからない場合は、29.1.2項「ユースケースの決定」を参照してください。
2. GitRepo/バンドルの設定オプションについては、29.3.4.1項「SUC Planのデプロイメント - GitRepoリソース」または29.3.4.2項「SUC Planのデプロイメント - バンドルリソース」を参照してください。
ユーザは設定済みのGitRepo/バンドルリソースを自身の管理クラスタのfleet-defaultネームスペースにデプロイします。これは、手動または使用可能な場合はRancher UIから実行できます。
Fleet (第6章「Fleet」)は、fleet-defaultネームスペースを絶えず監視し、新しくデプロイされたGitRepo/バンドルリソースをすぐに検出します。Fleetが監視するネームスペースの詳細については、Fleetの「Namespaces (ネームスペース)」のドキュメントを参照してください。
ユーザがGitRepoリソースをデプロイした場合、Fleetは、GitRepoを調整し、そのパスとfleet.yamlの設定に基づいて、バンドルリソースをfleet-defaultネームスペースにデプロイします。詳細については、Fleetの「Git Repository Contents (Gitリポジトリの内容)」のドキュメントを参照してください。
Fleetは続いて、Kubernetesリソースをこのバンドルから、ターゲットとするすべてのダウンストリームクラスタにデプロイします。Kubernetesバージョンのアップグレードのコンテキストでは、Fleetは、次のリソースをバンドル からデプロイします(Kubernetesディストリビューションによって異なります)。
1. rke2-upgrade-worker/k3s-upgrade-worker - クラスタ ワーカーノードでKubernetesをアップグレードする方法をSUCに指示します。クラスタが コントロールプレーンノードからのみ構成されている場合は解釈「されません」。
2. rke2-upgrade-control-plane/k3s-upgrade-control-plane - クラスタのコントロールプレーンノードでKubernetesをアップグレードする方法をSUCに指示します。
  注記
  上記のSUC Planは、各ダウンストリームクラスタのcattle-systemネームスペースにデプロイされます。
ダウンストリームクラスタで、SUCは、新しくデプロイされたSUC Planを検出し、SUC Planで定義されたノードセレクタと一致する各ノードに更新Podをデプロイします。SUC Plan Podを監視する方法については、 19.3項「System Upgrade Controller Planのモニタリング」を参照してください。
デプロイしたSUC Planに応じて、更新Podは、rke2-upgradeイメージまたはk3s-upgradeイメージのいずれかを実行して、それぞれのクラスタノードで次のワークフローを実行します。
1. Cordonクラスタノード - ノードのアップグレード時にこのノードにPodが誤ってスケジュールされないようにするために、このノードをunschedulableとマークします。
2. ノードOSにインストールされているrke2/k3sバイナリを、Podが現在実行しているrke2-upgrade/k3s-upgradeイメージによって配布されるバイナリに置き換えます。
3. ノードOSで実行されているrke2/k3sプロセスを強制終了します - これにより、新しいバージョンを使用してrke2/k3sプロセスを自動的に再起動するようにスーパーバイザに指示します。
4. Uncordonクラスタノード - Kubernetesディストリビューションの正常なアップグレード後、ノードはもう一度schedulableとマークされます。
  注記
  rke2-upgradeイメージおよびk3s-upgradeイメージの機能の詳細については、rke2-upgradeおよびk3s-upgradeのアップストリームプロジェクトを参照してください。

上記の手順を実行すると、各クラスタノードのKubernetesバージョンが目的のEdge互換リリースにアップグレードされているはずです。

29.3.4 Kubernetesバージョンアップグレード - SUC Planのデプロイメント #

このセクションでは、Fleetの GitRepoおよびバンドルリソースを使用して SUC Plan関連のKubernetesアップグレードのデプロイメントを調整する方法について説明します。

29.3.4.1 SUC Planのデプロイメント - GitRepoリソース #

必要なKubernetesアップグレードSUC Planを配布するGitRepoリソースは、次のいずれかの方法でデプロイできます。

Rancher UIを使用する - 29.3.4.1.1項「GitRepoの作成 - Rancher UI」 (Rancherが利用可能な場合)。
リソースを管理クラスタに手動でデプロイする(29.3.4.1.2項「GitRepoの作成 - 手動」)。

デプロイ後に、ターゲットクラスタのノードのKubernetesアップグレードプロセスを監視するには、19.3項「System Upgrade Controller Planのモニタリング」ドキュメントを参照してください。

29.3.4.1.1 GitRepoの作成 - Rancher UI #

Rancher UIを通じてGitRepoリソースを作成するには、公式のドキュメントに従ってください。

Edgeチームは、ユーザがGitRepoリソースのパスとして追加できるrke2とk3s Kubernetesディストリビューションのすぐに使用できるフリートを維持しています。

重要

常に有効なEdge リリースタグからこのフリートを使用します。

これらのフリートが配布するSUC Planにカスタム許容値を含める必要がないユースケースの場合、ユーザはsuse-edge/fleet-examplesリポジトリからフリートを直接参照できます。

カスタム許容値が必要な場合、ユーザは別のリポジトリからフリートを参照して、必要に応じてSUC Planに許容値を追加できるようにする必要があります。

suse-edge/fleet-examplesリポジトリからフリートを使用したGitRepoリソースの設定例は、次のとおりです。

29.3.4.1.2 GitRepoの作成 - 手動 #

GitRepoリソースをプルします。

RKE2クラスタの場合:

curl -o rke2-upgrade-gitrepo.yaml https://raw.githubusercontent.com/suse-edge/fleet-examples/refs/tags/release-3.1.2/gitrepos/day2/rke2-upgrade-gitrepo.yaml

K3sクラスタの場合:

curl -o k3s-upgrade-gitrepo.yaml https://raw.githubusercontent.com/suse-edge/fleet-examples/refs/tags/release-3.1.2/gitrepos/day2/k3s-upgrade-gitrepo.yaml

GitRepo設定を編集し、spec.targetsで目的のターゲットリストを指定します。デフォルトでは、suse-edge/fleet-examplesのGitRepoリソースはどのダウンストリームクラスタにもマップ「されません」。
- すべてのクラスタ変更に一致させるには、デフォルトのGitRepoターゲットを次のように変更します。
```
spec:
  targets:
  - clusterSelector: {}
```
- または、クラスタをより細かく選択したい場合は、「Mapping to Downstream Cluster (ダウンストリームクラスタへのマップ)」を参照してください

GitRepoリソースを管理クラスタに適用します。

# RKE2
kubectl apply -f rke2-upgrade-gitrepo.yaml

# K3s
kubectl apply -f k3s-upgrade-gitrepo.yaml

fleet-defaultネームスペースで、作成した GitRepoリソースを表示します。

# RKE2
kubectl get gitrepo rke2-upgrade -n fleet-default

# K3s
kubectl get gitrepo k3s-upgrade -n fleet-default

# Example output
NAME           REPO                                              COMMIT          BUNDLEDEPLOYMENTS-READY   STATUS
k3s-upgrade    https://github.com/suse-edge/fleet-examples.git   release-3.1.2   0/0
rke2-upgrade   https://github.com/suse-edge/fleet-examples.git   release-3.1.2   0/0

29.3.4.2 SUC Planのデプロイメント - バンドルリソース #

必要なKubernetesアップグレードSUC Planを配布するバンドルリソースは、次のいずれかの方法でデプロイできます。

Rancher UIを使用する - 29.3.4.2.1項「バンドルの作成 - Rancher UI」 (Rancherが利用可能な場合)。
リソースを管理クラスタに手動でデプロイする(29.3.4.2.2項「バンドルの作成 - 手動」)。

29.3.4.2.1 バンドルの作成 - Rancher UI #

Edgeチームは、以下の手順で使用可能なrke2とk3s Kubernetesディストリビューションのすぐに使用できるバンドルを維持しています。

重要

このバンドルは常に有効なEdgeリリースタグから使用してください。

RancherのUIを通じてバンドルを作成するには、次の手順に従います。

左上隅で、［☰］ → ［Continuous Delivery (継続的デリバリ)］をクリックします。
［Advanced (詳細)］>［Bundles (バンドル)］ に移動します。
［Create from YAML (YAMLから作成)］を選択します。
ここから次のいずれかの方法でバンドルを作成できます。
注記
バンドルが配布する SUC planにカスタム許容値を含める必要があるユースケースがある場合があります。以下の手順で生成されるバンドルには、必ずこれらの許容値を含めるようにします。
1. suse-edge/fleet-examplesから［Create from YAML (YAMLから作成)］ページにRKE2またはK3sのバンドルコンテンツを手動でコピーする。
2. 目的のリリースタグからsuse-edge/fleet-examplesリポジトリのクローンを作成し、［Create from YAML (YAMLから作成)］ページの［Read from File (ファイルから読み取り)］オプションを選択する。そこから、必要なバンドルに移動します(RKE2の場合はbundles/day2/system-upgrade-controller-plans/rke2-upgrade/plan-bundle.yaml、K3sの場合はbundles/day2/system-upgrade-controller-plans/k3s-upgrade/plan-bundle.yaml)。［Create from YAML (YAMLから作成)］ページにバンドルコンテンツが自動的に入力されます。
バンドルのターゲットクラスタを次のように変更します。
- すべてのダウンストリームクラスタに一致させるには、デフォルトのバンドル.spec.targetsを次のように変更します。
```
spec:
  targets:
  - clusterSelector: {}
```
- より細かくダウンストリームクラスタにマッピングするには、「Mapping to Downstream Clusters (ダウンストリームクラスタへのマップ)」を参照してください。
作成します

29.3.4.2.2 バンドルの作成 - 手動 #

バンドルリソースをプルします。

RKE2クラスタの場合:

curl -o rke2-plan-bundle.yaml https://raw.githubusercontent.com/suse-edge/fleet-examples/refs/tags/release-3.1.2/bundles/day2/system-upgrade-controller-plans/rke2-upgrade/plan-bundle.yaml

K3sクラスタの場合:

curl -o k3s-plan-bundle.yaml https://raw.githubusercontent.com/suse-edge/fleet-examples/refs/tags/release-3.1.2/bundles/day2/system-upgrade-controller-plans/k3s-upgrade/plan-bundle.yaml

バンドルのターゲット設定を編集し、spec.targetsに目的のターゲットリストを指定します。デフォルトでは、suse-edge/fleet-examplesのバンドルリソースは、どのダウンストリームクラスタにもマップ「されません」。
- すべてのクラスタに一致させるには、デフォルトのバンドルのターゲットを次のように変更します。
```
spec:
  targets:
  - clusterSelector: {}
```
- または、クラスタをより細かく選択したい場合は、「Mapping to Downstream Cluster (ダウンストリームクラスタへのマップ)」を参照してください

バンドルリソースを管理クラスタに適用します。

# For RKE2
kubectl apply -f rke2-plan-bundle.yaml

# For K3s
kubectl apply -f k3s-plan-bundle.yaml

fleet-defaultネームスペースで、作成したバンドルリソースを表示します。

# For RKE2
kubectl get bundles rke2-upgrade -n fleet-default

# For K3s
kubectl get bundles k3s-upgrade -n fleet-default

# Example output
NAME           BUNDLEDEPLOYMENTS-READY   STATUS
k3s-upgrade    0/0
rke2-upgrade   0/0

29.3.4.3 SUC Planのデプロイメント - サードパーティのGitOpsワークフロー #

ユーザがKubernetesアップグレードリソースを独自のサードパーティGitOpsワークフロー(Fluxなど)に統合したいユースケースが存在する場合があります。

必要なアップグレードリソースを取得するには、まず、使用するsuse-edge/fleet-examplesリポジトリのEdgeリリースタグを特定します。

その後、次の場所でリソースを確認できます。

RKE2クラスタのアップグレードの場合:
- control-planeノード用 - fleets/day2/system-upgrade-controller-plans/rke2-upgrade/plan-control-plane.yaml
- ワーカーノードの場合 - fleets/day2/system-upgrade-controller-plans/rke2-upgrade/plan-worker.yaml
K3sクラスタのアップグレードの場合:
- control-planeノード用 - fleets/day2/system-upgrade-controller-plans/k3s-upgrade/plan-control-plane.yaml
- ワーカーノードの場合 - fleets/day2/system-upgrade-controller-plans/k3s-upgrade/plan-worker.yaml

重要

GitOpsワークフローを使用してKubernetesバージョンアップグレード用のSUC Planをデプロイする方法について理解を深めるには、Fleetを使用した更新手順の概要(29.3.3.1項「概要」)を確認すると役に立ちます。

29.4 Helmチャートのアップグレード #

注記

以下の各セクションでは、Fleetの機能を使用してHelmチャートの更新を実現する方法を中心に説明します。

サードパーティのGitOpsツールの使用が必要なユースケースの場合は、以下を参照してください。

EIBでデプロイされたHelmチャートのアップグレードの場合 - 29.4.3.3.4項「サードパーティのGitOpsツールを使用したHelmチャートのアップグレード」。
EIB以外でデプロイされたHelmチャートのアップグレードの場合 - リリースノート(45.1項「要約」)ページから目的のEdgeリリースによってサポートされているチャートバージョンを取得し、サードパーティのGitOpsツールにチャートバージョンとURLを入力します。

29.4.1 コンポーネント #

この操作には、デフォルトのDay 2コンポーネント(29.1.1項「コンポーネント」)以外のカスタムコンポーネントは不要です。

29.4.2 エアギャップ環境の準備 #

29.4.2.1 HelmチャートのアップグレードFleetにアクセスできることの確認 #

環境でサポートする内容によって、次のオプションのいずれかを選択できます。

管理クラスタからアクセス可能なローカルGitサーバでチャートのFleetリソースをホストします。
FleetのCLIを使用して直接使用可能で、どこかにホストする必要のないバンドルにHelmチャートを変換します。FleetのCLIは、リリースページから取得できます。Macユーザの場合は、 fleet-cli Homebrew Formulaeがあります。

29.4.2.2 Edgeリリースバージョンに必要なアセットの検索 #

Day 2リリースのページに移動し、チャートのアップグレード先のEdge 3.X.Yリリースを見つけ、［Assets (アセット)］をクリックします。

［Assets (アセット)］セクションから、次のファイルをダウンロードします。

リリースファイル	説明
edge-save-images.sh	`edge-release-images.txt`ファイルで指定されたイメージを取得し、それらを「.tar.gz」アーカイブにパッケージ化します。
edge-save-oci-artefacts.sh	特定のEdgeリリースに関連するOCIチャートイメージを取得し、それらを「.tar.gz」アーカイブにパッケージ化します。
edge-load-images.sh	「.tar.gz」アーカイブからイメージをロードし、再タグ付けして、プライベートレジストリにプッシュします。
edge-load-oci-artefacts.sh	Edge OCI「.tgz」チャートパッケージを含むディレクトリを取得し、それらをプライベートレジストリにロードします。
edge-release-helm-oci-artefacts.txt	特定のEdgeリリースに関連するOCIチャートイメージのリストを含みます。
edge-release-images.txt	特定のEdgeリリースに関連するイメージのリストを含みます。

29.4.2.3 Edgeリリースイメージアーカイブの作成 #

インターネットにアクセスできるマシンで次の手順を実行します。

edge-save-images.shを実行可能にします。
```
chmod +x edge-save-images.sh
```

イメージアーカイブを生成します。

./edge-save-images.sh --source-registry registry.suse.com

これにより、edge-images.tar.gzという名前のすぐにロードできるアーカイブが作成されます。
注記
-i|--imagesオプションが指定される場合、アーカイブの名前は異なる場合があります。
このアーカイブをエアギャップマシンにコピーします。
```
scp edge-images.tar.gz <user>@<machine_ip>:/path
```

29.4.2.4 Edge OCIチャートイメージアーカイブの作成 #

インターネットにアクセスできるマシンで次の手順を実行します。

edge-save-oci-artefacts.shを実行可能にします。
```
chmod +x edge-save-oci-artefacts.sh
```

OCIチャートイメージアーカイブを生成します。

./edge-save-oci-artefacts.sh --source-registry registry.suse.com

これにより、 oci-artefacts.tar.gzという名前のアーカイブが作成されます。
注記
-a|--archiveオプションが指定される場合、アーカイブの名前は異なる場合があります。
このアーカイブをエアギャップマシンにコピーします。
```
scp oci-artefacts.tar.gz <user>@<machine_ip>:/path
```

29.4.2.5 Edgeリリースイメージをエアギャップマシンにロード #

エアギャップマシンで次の手順を実行します。

プライベートレジストリにログインします(必要な場合)。
```
podman login <REGISTRY.YOURDOMAIN.COM:PORT>
```
edge-load-images.shを実行可能にします。
```
chmod +x edge-load-images.sh
```
以前にコピーした edge-images.tar.gzアーカイブを渡して、スクリプトを実行します。
```
./edge-load-images.sh --source-registry registry.suse.com --registry <REGISTRY.YOURDOMAIN.COM:PORT> --images edge-images.tar.gz
```
注記
これにより、edge-images.tar.gzからすべてのイメージがロードされ、再タグ付けされて、それらを--registryオプションで指定されているレジストリにプッシュします。

29.4.2.6 Edge OCIチャートイメージのエアギャップマシンへのロード #

エアギャップマシンで次の手順を実行します。

プライベートレジストリにログインします(必要な場合)。
```
podman login <REGISTRY.YOURDOMAIN.COM:PORT>
```
edge-load-oci-artefacts.shを実行可能にします。
```
chmod +x edge-load-oci-artefacts.sh
```
コピーしたoci-artefacts.tar.gzアーカイブをuntarします。
```
tar -xvf oci-artefacts.tar.gz
```
命名テンプレートedge-release-oci-tgz-<date>を含むディレクトリが生成されます。
このディレクトリをedge-load-oci-artefacts.shスクリプトに渡し、Edge OCIチャートイメージをプライベートレジストリにロードします。
注記
このスクリプトは、Helm CLIが環境にプリインストールされていることを想定しています。Helmのインストール手順については、「Helmのインストール」を参照してください。
```
./edge-load-oci-artefacts.sh --archive-directory edge-release-oci-tgz-<date> --registry <REGISTRY.YOURDOMAIN.COM:PORT> --source-registry registry.suse.com
```

29.4.2.7 Kubernetesディストリビューションのプライベートレジストリを指すレジストリミラーの作成 #

RKE2の場合は、「Containerd Registry Configuration (Containerdレジストリの設定)」を参照してください。

K3sの場合は、「埋め込みレジストリミラー」を参照してください。

29.4.3 アップグレード手順 #

このセクションでは、Helmアップグレード手順の次のユースケースを中心に説明します。

新しいクラスタがあり、SUSE Helmチャートをデプロイして管理したい(29.4.3.1項「新しいクラスタがあり、SUSE Helmチャートをデプロイして管理したい場合」)
Fleetで管理されているHelmチャートをアップグレードしたい(29.4.3.2項「Fleetで管理されているHelmチャートをアップグレードしたい場合」)
EIBでデプロイされたHelmチャートをアップグレードしたい(29.4.3.3項「EIBでデプロイされたHelmチャートをアップグレードしたい」)

重要

手動でデプロイしたHelmチャートを確実にアップグレードすることはできません。29.4.3.1項「新しいクラスタがあり、SUSE Helmチャートをデプロイして管理したい場合」で説明する方法を使用してHelmチャートを再デプロイすることをお勧めします。

29.4.3.1 新しいクラスタがあり、SUSE Helmチャートをデプロイして管理したい場合 #

Fleetを使用してHelmチャートのライフサイクルを管理したいユーザが対象です。

このセクションでは、以下の実行方法について説明します。

Fleetリソースの準備(29.4.3.1.1項「Fleetリソースの準備」)。
Fleetリソースのデプロイ(29.4.3.1.2項「Fleetのデプロイ」)。
デプロイされたHelmチャートの管理(29.4.3.1.3項「デプロイされたHelmチャートの管理」)。

29.4.3.1.1 Fleetリソースの準備 #

チャートのFleetリソースを、使用するEdgeリリースタグから取得します。
1. 選択したEdgeリリースタグのリビジョンから、HelmチャートのFleet (fleets/day2/chart-templates/<chart>)に移動します。
2. GitOpsワークフローを使用する場合は、チャートFleetディレクトリをGitOpsを実行するGitリポジトリにコピーします。
3. (任意) Helmチャートで値を設定する必要がある場合は、コピーしたディレクトリのfleet.yamlファイルに含まれる設定.helm.valuesを編集します。
4. (任意) 環境に合わせて、チャートのFleetにリソースを追加しなければならないユースケースがあります。Fleetディレクトリを拡張する方法については、「Git Repository Contents (Gitリポジトリのコンテンツ)」を参照してください。

longhorn Helmチャートの例は次のようになります。

ユーザGitリポジトリ構造:

<user_repository_root>
├── longhorn
│   └── fleet.yaml
└── longhorn-crd
    └── fleet.yaml

ユーザのlonghornデータが入力されたfleet.yaml の内容:

defaultNamespace: longhorn-system

helm:
  releaseName: "longhorn"
  chart: "longhorn"
  repo: "https://charts.rancher.io/"
  version: "104.2.2+up1.7.3"
  takeOwnership: true
  # custom chart value overrides
  values:
    # Example for user provided custom values content
    defaultSettings:
      deletingConfirmationFlag: true

# https://fleet.rancher.io/bundle-diffs
diff:
  comparePatches:
  - apiVersion: apiextensions.k8s.io/v1
    kind: CustomResourceDefinition
    name: engineimages.longhorn.io
    operations:
    - {"op":"remove", "path":"/status/conditions"}
    - {"op":"remove", "path":"/status/storedVersions"}
    - {"op":"remove", "path":"/status/acceptedNames"}
  - apiVersion: apiextensions.k8s.io/v1
    kind: CustomResourceDefinition
    name: nodes.longhorn.io
    operations:
    - {"op":"remove", "path":"/status/conditions"}
    - {"op":"remove", "path":"/status/storedVersions"}
    - {"op":"remove", "path":"/status/acceptedNames"}
  - apiVersion: apiextensions.k8s.io/v1
    kind: CustomResourceDefinition
    name: volumes.longhorn.io
    operations:
    - {"op":"remove", "path":"/status/conditions"}
    - {"op":"remove", "path":"/status/storedVersions"}
    - {"op":"remove", "path":"/status/acceptedNames"}

注記

これらは値の例であり、longhornチャートのカスタム設定を示すために使用しているだけです。longhornチャートのデプロイメントのガイドラインと「みなさない」でください。

29.4.3.1.2 Fleetのデプロイ #

環境がGitOpsワークフローの操作をサポートしている場合は、GitRepo (29.4.3.1.2.1項「GitRepo」)またはバンドル(29.4.3.1.2.2項「バンドル」)のいずれかを使用してチャートFleetをデプロイできます。

注記

Fleetをデプロイする場合に、Modifiedメッセージを取得した場合、Fleetのdiffセクションに対応するcomparePatchesエントリを追加してください。詳細については、「Generating Diffs to Ignore Modified GitRepos (変更されたGitReposを無視する差分を生成する) 」を参照してください。

29.4.3.1.2.1 GitRepo #

FleetのGitRepoリソースは、チャートのFleetリソースへのアクセス方法、それらのリソースを適用するのに必要なクラスタに関する情報を保持しています。

GitRepoリソースは、 Rancher UIを通じて、または手動で管理クラスタにリソースをデプロイすることで、デプロイできます。

手動デプロイメントのLonghorn GitRepoリソースの例

apiVersion: fleet.cattle.io/v1alpha1
kind: GitRepo
metadata:
  name: longhorn-git-repo
  namespace: fleet-default
spec:
  # If using a tag
  # revision: <user_repository_tag>
  #
  # If using a branch
  # branch: <user_repository_branch>
  paths:
  # As seen in the 'Prepare your Fleet resources' example
  - longhorn
  - longhorn-crd
  repo: <user_repository_url>
  targets:
  # Match all clusters
  - clusterSelector: {}

29.4.3.1.2.2 バンドル #

バンドルリソースは、Fleetによってデプロイされる必要がある生のKubernetesリソースを保持しています。通常、GitRepoアプローチを使用することを推奨されますが、環境がエアギャップされ、ローカルGitサーバをサポートできないユースケース用に、バンドルがHelmチャートFleetをターゲットクラスタに伝播するのに役立ちます。

バンドルは、Rancher UI (Continuous Delivery (継続的デリバリ) → Advanced (詳細) → Bundles (バンドル) → Create from YAML (YALMから作成))を介して、またはバンドルリソースを正しいネームスペースに手動でデプロイして、デプロイできます。Fleetネームスペースについては、アップストリームドキュメントを参照してください。

手動による アプローチを使用したLonghorn バンドルリソースデプロイメントの例:

fleets/day2/chart-templates/longhorn/longhornにあるLonghornチャートフリートに移動します。
```
cd fleets/day2/chart-templates/longhorn/longhorn
```
HelmチャートをデプロイするクラスタをFleetに指示する targets.yamlファイルを作成します。この場合、1台のダウストリームクラスにデプロイされます。複雑なターゲットをマッピングする方法については「Mapping to Downstream Clusters (ダウンストリームクラスタへのマッピング」を参照してください。
```
cat > targets.yaml <<EOF
targets:
- clusterName: foo
EOF
```
Longhorn HelmチャートFleetをバンドルリソースに変換します。詳細については、「Convert a Helm Chart into a Bundle (Helmチャートのバンドルへの変換)」を参照してください。
```
fleet apply --compress --targets-file=targets.yaml -n fleet-default -o - longhorn-bundle > longhorn-bundle.yaml
```
fleets/day2/chart-templates/longhorn/longhorn-crdにあるLonghorn CRDチャートフリートに移動します。
```
cd fleets/day2/chart-templates/longhorn/longhorn-crd
```
HelmチャートをデプロイするクラスタをFleetに指示する targets.yamlファイルを作成します。この場合、1台のダウストリームクラスにデプロイされます。複雑なターゲットをマッピングする方法については「Mapping to Downstream Clusters (ダウンストリームクラスタへのマッピング」を参照してください。
```
cat > targets.yaml <<EOF
targets:
- clusterName: foo
EOF
```
Longhorn CRD HelmチャートFleetをバンドルリソースに変換します。詳細については、「Convert a Helm Chart into a Bundle (Helmチャートのバンドルへの変換)」を参照してください。
```
fleet apply --compress --targets-file=targets.yaml -n fleet-default -o - longhorn-crd-bundle > longhorn-crd-bundle.yaml
```
longhorn-bundle.yamlとlonghorn-crd-bundle.yamlを管理クラスタにデプロイします。
```
kubectl apply -f longhorn-crd-bundle.yaml
kubectl apply -f longhorn-bundle.yaml
```

これらの手順に従うと、Longhornが指定されたターゲットクラスタのすべてにデプロイされます。

29.4.3.1.3 デプロイされたHelmチャートの管理 #

Fleetでデプロイした後のHelmチャートのアップグレードについては、29.4.3.2項「Fleetで管理されているHelmチャートをアップグレードしたい場合」を参照してください。

29.4.3.2 Fleetで管理されているHelmチャートをアップグレードしたい場合 #

目的のEdgeリリースと互換性を持つように、チャートをアップブレードする必要があるバージョンを決定します。EdgeリリースごとのHelmチャートバージョンはリリースノート45.1項「要約」)から表示できます。
Fleetで監視されているGitリポジトリで、Helmチャートのfleet.yamlファイルを、リリースノート(45.1項「要約」)から取得した正しいチャートバージョンとリポジトリで編集します。
変更をコミットしてリポジトリにプッシュした後で、目的のHelmチャートのアップグレードがトリガされます。

29.4.3.3 EIBでデプロイされたHelmチャートをアップグレードしたい #

EIBは、HelmChartリソースを作成し、 RKE2/K3s Helm 統合機能によって導入されたhelm-controllerを利用することで、Helmチャートをデプロイします。

EIBで導入されたHelmチャートが正常にアップグレードされるように、ユーザはEIBによってHelmチャート用に作成されたHelmChartリソースに対してアップグレードを実行する必要があります。

以下に関する情報が提供されています。

EIBでデプロイされたHelmチャートアップグレードプロセスの一般的な概要(29.4.3.3.1項「概要」)。
EIBでデプロイされたHelmチャートの正常なアップグレードに必要なアップグレード手順(29.4.3.3.2項「アップグレード手順」)。
説明されていた方法を使用してLonghornチャートをアップグレードする方法を示す例(29.4.3.3.3項「例」)。
異なるGitOpsツールでアップグレードプロセスを使用する方法(29.4.3.3.4項「サードパーティのGitOpsツールを使用したHelmチャートのアップグレード」)。

29.4.3.3.1 概要 #

このセクションは、EIBによってデプロイされた1つまたは複数のHelmチャートをアップグレードするために実行する必要がある手順の概要を説明することを目的としています。Helmチャートのアップグレードに必要な手順の詳細な説明については、29.4.3.3.2項「アップグレード手順」を参照してください。

図 29.3: Helmチャートのアップグレードワークフロー #

このワークフローでは最初に、チャートのアップグレード先にする新しいHelmチャートアーカイブをユーザがプルします。
アーカイブは、 generate-chart-upgrade-data.shスクリプトによって処理されるディレクトリに配置される必要があります。
次にユーザは、generate-chart-upgrade-data.shスクリプトを実行します。これにより、提供されたアーカイブディレクトリの各Helmチャートアーカイブに対応するKubernetes Secret YAMLファイルが生成されます。これらのシークレットは、Helmチャートをアップグレードするために使用されるFleetに自動的に配置されます。これは、アップグレード手順(29.4.3.3.2項「アップグレード手順」)セクションで詳細に説明されています。
スクリプトが正常に終了したら、ユーザは必要なすべてのK8sリソースをターゲットクラスタに配布するバンドルまたはGitRepoリソースのいずれかの設定とデプロイメントを続行します。
1. リソースはfleet-defaultネームスペースの管理クラスタにデプロイされます。
Fleet (第6章「Fleet」)はデプロイされたリソースを検出し、そのデータを解析して、そのリソースを指定されたターゲットクラスタにデプロイします。デプロイされる最も注目すべきリソースは次のとおりです。
1. eib-charts-upgrader - チャートアップグレードPodをデプロイするジョブ。eib-charts-upgrader-scriptとhelm chart upgrade dataシークレットがチャートアップグレードPod内にマウントされます。
2. eib-charts-upgrader-script - 既存のHelmChartリソースにパッチを適用するために、チャートアップグレードPodによって使用されるスクリプトを配布するシークレット。
3. Helmチャートアップグレードデータシークレット - ユーザが提供するデータに基づいてgenerate-chart-upgrade-data.shスクリプトによって作成されたシークレットYAMLファイル。
チャートアップグレードPodがデプロイされると、eib-charts-upgrader-scriptシークレットのスクリプトが実行され、以下が実行されます。
1. 他のシークレットによって提供されたすべてのHelmチャートアップグレードを処理します。
2. 提供されたアップグレードデータのそれぞれに対してHelmChartリソースがあるかどうかを確認します。
3. 対応するHelmチャートのシークレットから提供されるデータでHelmChartリソースにパッチを適用します。
RKE2/K3s helm-controllerは絶えず既存のHelmChartリソースに対する編集を監視します。 HelmChart のパッチを検出し、変更を調整して、HelmChartリソースの背後のチャートのアップグレードに進みます。

29.4.3.3.2 アップグレード手順 #

使用するEdge リリースタグからsuse-edge/fleet-examplesリポジトリのクローンを作成します。
取得したHelmチャートアーカイブを保存するディレクトリを作成します。
```
mkdir archives
```

新しく作成したアーカイブディレクトリ内で、アップグレードするHelmチャートアーカイブを取得します。

cd archives
helm pull [chart URL | repo/chartname]

# Alternatively if you want to pull a specific version:
# helm pull [chart URL | repo/chartname] --version 0.0.0

目的のリリースタグから、generate-chart-upgrade-data.shスクリプトをダウンロードします。
generate-chart-upgrade-data.shスクリプトを実行します。
重要
ユーザは、generate-chart-upgrade-data.shスクリプトが生成する内容に変更を加えてはなりません。
```
chmod +x ./generate-chart-upgrade-data.sh

./generate-chart-upgrade-data.sh --archive-dir /foo/bar/archives/ --fleet-path /foo/bar/fleet-examples/fleets/day2/eib-charts-upgrader
```
スクリプトは次の論理を実行します。
1. ユーザは、 --fleet-pathを指定して、Helmチャートアップグレードを開始できる有効なFleetを指していることを検証します。
2. ユーザが作成したアーカイブディレクトリ(例: /foo/bar/archives/)からのすべてHelmチャートアーカイブを処理します。
3. Helmチャートアーカイブごとに、Kubernetes Secret YAMLリソースが作成されます。このリソースには、以下が保持されます。
  1. パッチを適用する必要があるHelmChartリソースの名前。
  2. HelmChartリソースの新しい バージョン。
  3. HelmChartの現在実行中の設定を置き換えるために使用されるbase64でエンコードされたHelmチャートアーカイブ。
4. 各Kubernetes Secret YAMLリソースは、--fleet-pathで指定されたeib-charts-upgrader Fleetへのパス内のbase/secretsディレクトリに転送されます。
5. さらに、generate-chart-upgrade-data.shスクリプトは、移動したシークレットが確実に取得され、Helmチャートアップグレード論理で使用されるようにします。これは次のようにして行われます。
  1. 新しく追加されたリソースを含むようにbase/secrets/kustomization.yamlファイルを編集する。
  2. 新しく追加されたシークレットをマウント設定に含むようにbase/patches/job-patch.yamlファイルを編集する。
generate-chart-upgrade-data.shが正常に実行されたら、suse-edge/fleet-examplesリポジトリの次のディレクトリ内に変更が反映されているはずです。
1. fleets/day2/eib-charts-upgrader/base/patches
2. fleets/day2/eib-charts-upgrader/base/secrets

以下の手順は、実行している環境によって異なります。

GitOpsをサポートする環境の場合(例: エアギャップされていない、エアギャップされたがローカルGitサーバーサポートが可能):
1. fleets/day2/eib-charts-upgrader FleetをGitOpsに使用するリポジトリにコピーします。Fleetにgenerate-chart-upgrade-data.shスクリプトによって加えられた変更が含まれていることを確認します。
2. eib-charts-upgrader Fleetのすべてのリソースを配布するために使用されるGitRepoリソースを設定します。
  1. Rancher UIを通じてGitRepoを設定およびデプロイする場合、「Accessing Fleet in the Rancher UI (Rancher UIでのFleetへのアクセス)」を参照してください。
  2. GitRepo手動設定およびデプロイメントの場合、「Creating a Deployment (デプロイメントの作成)」を参照してください。
GitOpsをサポートしていない環境の場合 (例: エアギャップされ、ローカルGitサーバの使用が許可されていない):
1. rancher/fleetリリースページからfleet-cliバイナリをダウンロードします。Macユーザの場合、使用可能なHomebrew Formulaeがあります - fleet-cli。
2. eib-charts-upgrader Fleetに移動します。
```
cd /foo/bar/fleet-examples/fleets/day2/eib-charts-upgrader
```
3. リソースをデプロイする場所をFleetに指示するtargets.yamlファイルを作成します。
```
cat > targets.yaml <<EOF
targets:
- clusterSelector: {} # Change this with your target data
EOF
```
  ターゲットクラスタをマップする方法については、アップストリームドキュメントを参照してください。
4. fleet-cliを使用して、Fleetを バンドルリソースに変換します。
```
fleet apply --compress --targets-file=targets.yaml -n fleet-default -o - eib-charts-upgrade > bundle.yaml
```
  これにより、eib-charts-upgrader Fleetからのすべてのテンプレート化されたリソースを保持するバンドル(bundle.yaml)が作成されます。
  fleet applyコマンドに関する詳細については、「fleet apply」を参照してください。
  Fleetをバンドルに変換する方法に関する詳細については、「 Convert a Helm Chart into a Bundle (Helmチャートのバンドルへの変換)」を参照してください。
5. バンドルをデプロイします。これは2つの方法のいずれかで実行できます。
  1. RancherのUIを通じて - ［Continuous Delivery (継続的デリバリ)］→［Advanced (詳細)］→［Bundles (バンドル)］ → ［Create from YAML (YAMLから作成)］に移動して、bundle.yaml コンテンツを解析するか、［Read from File (ファイルから読み取り)］オプションをクリックして、ファイル自体を渡します。
  2. 手動 - 管理クラスタ内にbundle.yamlファイルを手動でデプロイします。

これらの手順を実行すると、正常にGitRepo/バンドルリソースがデプロイされます。リソースはFleetによって取得され、そのコンテンツはユーザが以前の手順で指定したターゲットクラスタにデプロイされます。プロセスの概要については、「概要」(29.4.3.3.1項「概要」)セクションを参照してください。

アップグレードプロセスを追跡する方法については、このドキュメントの「例」(29.4.3.3.3項「例」)セクションを参照してください。

重要

チャートアップグレードが正常に確認されたら、バンドル/GitRepoリソースを削除します。

これにより、ダウンストリームクラスタから不要になったアップグレードリソースが削除され、今後バージョンクラッシュが発生しないようになります。

29.4.3.3.3 例 #

注記

以下の例は、あるバージョンから別のバージョンにEIBでデプロイされたHelmチャートのアップグレード方法を示しています。この例のバージョンは、バージョン推奨事項として 「扱わない」でください。特定のEdgeリリースのバージョン推奨事項は、リリースノート(45.1項「要約」)を参照してください。

ユースケース:

クラスタ名doc-exampleがRancherのLonghorn 103.3.0+up1.6.1バージョンを実行しています。

クラスタは、次のイメージ定義スニペットを使用して、EIBを通じてデプロイされました。

kubernetes:
  helm:
    charts:
    - name: longhorn-crd
      repositoryName: rancher-charts
      targetNamespace: longhorn-system
      createNamespace: true
      version: 103.3.0+up1.6.1
    - name: longhorn
      repositoryName: rancher-charts
      targetNamespace: longhorn-system
      createNamespace: true
      version: 103.3.0+up1.6.1
    repositories:
    - name: rancher-charts
      url: https://charts.rancher.io/
...

図 29.4: doc-exampleがインストールされたLonghornバージョン #

Longhornは、 Edge 3.1リリースと互換性のあるバージョンにアップグレードする必要があります。つまり、104.2.2+up1.7.3にアップグレードする必要があります。
doc-exampleクラスタの管理を担当する管理クラスタがローカルGitサーバのサポートなしでエアギャップされており、Rancherセットアップが動作していることを前提としています。

アップグレード手順(29.4.3.3.2項「アップグレード手順」)に従います。

release-3.1.2タグから suse-edge/fleet-exampleリポジトリのクローンを作成します。
```
git clone -b release-3.1.2 https://github.com/suse-edge/fleet-examples.git
```
Longhornアップグレードアーカイブが保存されるディレクトリを作成します。
```
mkdir archives
```

目的のLonghornチャートアーカイブバージョンを取得します。

# First add the Rancher Helm chart repository
helm repo add rancher-charts https://charts.rancher.io/

# Pull the Longhorn 1.7.3 CRD archive
helm pull rancher-charts/longhorn-crd --version 104.2.2+up1.7.3

# Pull the Longhorn 1.7.3 chart archive
helm pull rancher-charts/longhorn --version 104.2.2+up1.7.3

archivesディレクトリ以外で、release-3.1.2リリースタグからgenerate-chart-upgrade-data.shスクリプトをダウンロードします。

ディレクトリセットアップは次のようになるはずです。

.
├── archives
|   ├── longhorn-104.2.2+up1.7.3.tgz
│   └── longhorn-crd-104.2.2+up1.7.3.tgz
├── fleet-examples
...
│   ├── fleets
│   │   ├── day2
|   |   |   ├── ...
│   │   │   ├── eib-charts-upgrader
│   │   │   │   ├── base
│   │   │   │   │   ├── job.yaml
│   │   │   │   │   ├── kustomization.yaml
│   │   │   │   │   ├── patches
│   │   │   │   │   │   └── job-patch.yaml
│   │   │   │   │   ├── rbac
│   │   │   │   │   │   ├── cluster-role-binding.yaml
│   │   │   │   │   │   ├── cluster-role.yaml
│   │   │   │   │   │   ├── kustomization.yaml
│   │   │   │   │   │   └── sa.yaml
│   │   │   │   │   └── secrets
│   │   │   │   │       ├── eib-charts-upgrader-script.yaml
│   │   │   │   │       └── kustomization.yaml
│   │   │   │   ├── fleet.yaml
│   │   │   │   └── kustomization.yaml
│   │   │   └── ...
│   └── ...
└── generate-chart-upgrade-data.sh

generate-chart-upgrade-data.shスクリプトを実行します。

# First make the script executable
chmod +x ./generate-chart-upgrade-data.sh

# Then execute the script
./generate-chart-upgrade-data.sh --archive-dir ./archives --fleet-path ./fleet-examples/fleets/day2/eib-charts-upgrader

スクリプト実行後のディレクトリ構造は次のようになるはずです。

.
├── archives
|   ├── longhorn-104.2.2+up1.7.3.tgz
│   └── longhorn-crd-104.2.2+up1.7.3.tgz
├── fleet-examples
...
│   ├── fleets
│   │   ├── day2
│   │   │   ├── ...
│   │   │   ├── eib-charts-upgrader
│   │   │   │   ├── base
│   │   │   │   │   ├── job.yaml
│   │   │   │   │   ├── kustomization.yaml
│   │   │   │   │   ├── patches
│   │   │   │   │   │   └── job-patch.yaml
│   │   │   │   │   ├── rbac
│   │   │   │   │   │   ├── cluster-role-binding.yaml
│   │   │   │   │   │   ├── cluster-role.yaml
│   │   │   │   │   │   ├── kustomization.yaml
│   │   │   │   │   │   └── sa.yaml
│   │   │   │   │   └── secrets
│   │   │   │   │       ├── eib-charts-upgrader-script.yaml
│   │   │   │   │       ├── kustomization.yaml
│   │   │   │   │       ├── longhorn-104-2-0-up1-7-1.yaml <- secret created by the generate-chart-upgrade-data.sh script
│   │   │   │   │       └── longhorn-crd-104-2-0-up1-7-1.yaml <- secret created by the generate-chart-upgrade-data.sh script
│   │   │   │   ├── fleet.yaml
│   │   │   │   └── kustomization.yaml
│   │   │   └── ...
│   └── ...
└── generate-chart-upgrade-data.sh

Gitで変更されたファイルは次のようになるはずです。

図 29.5: generate-chart-upgrade-data.shによって作成されたfleet-examplesの変更 #

管理クラスタがGitOpsワークフローをサポートしていないため、バンドルはeib-charts-upgrader Fleet用に作成される必要があります。
1. まず、Fleet自体に移動します。
```
cd ./fleet-examples/fleets/day2/eib-charts-upgrader
```
2. 次に、doc-exampleクラスタをターゲットとするtargets.yamlファイルを作成します。
```
cat > targets.yaml <<EOF
targets:
- clusterName: doc-example
EOF
```
3. 次に、fleet-cliバイナリを使用して、Fleetをバンドルに変換します。
```
fleet apply --compress --targets-file=targets.yaml -n fleet-default -o - eib-charts-upgrade > bundle.yaml
```
4. ここで、 管理クラスタマシンにbundle.yamlを転送します。
管理クラスタがRancherを実行しているため、Rancher UIを通じてバンドルをデプロイします。
図 29.6: Rancher UIを通じたバンドルのデプロイ #

ここから、［Read from File (ファイルから読み取り)］を選択し、システムでbundle.yamlファイルを見つけます。
これにより、RancherのUI内にバンドルが自動入力されます。
図 29.7: 自動入力されたバンドルスニペット #

［Create (作成)］を選択します。
正常にデプロイされたら、バンドルは次のようになります。
図 29.8: 正常にデプロイされたバンドル #

バンドルのデプロイメントが成功した後で、アップグレードプロセスを監視するには次のようにします。

まず、アップグレードPodのログを確認します。
図 29.9: アップグレードポッドのログの表示 #
ここで、helm-controllerによってアップグレードに作成されたPodのログを確認します。
1. Pod名は次のテンプレートを使用します - helm-install-longhorn-<random-suffix>
2. Podは、HelmChartリソースがデプロイされたネームスペースにあります。この場合、これは、デフォルトです。
  図 29.10: 正常にアップグレードされたLonghornチャートのログ #
HelmChartバージョンが上がっていることを確認します。
図 29.11: 上がったLonghornのバージョン #
最後に、Longhorn Podが実行中であることを確認します。
図 29.12: instance-managerポッドの検証例 #

上記の検証後、Longhorn Helmチャートが103.3.0+up1.6.1から104.2.2+up1.7.3にアップグレードされていると仮定しても問題ないでしょう。

29.4.3.3.4 サードパーティのGitOpsツールを使用したHelmチャートのアップグレード #

ユーザがこのアップグレード手順をFleet以外のGitOpsワークフロー(Fluxなど)で実行したいユースケースが存在する場合があります。

アップグレード手順に必要なリソースを生成するには、generate-chart-upgrade-data.shスクリプトを使用して、ユーザが提供するデータをeib-charts-upgrader Fleetに入力することができます。この実行方法の詳細については、アップグレード手順(29.4.3.3.2項「アップグレード手順」)を参照してください。

完全なセットアップ後、kustomizeを使用して、クラスタにデプロイ可能な完全な動作ソリューションを生成することができます。

cd /foo/bar/fleets/day2/eib-charts-upgrader

kustomize build .

GitOpsワークフローにソリューションを含める場合は、fleet.yamlファイルを削除して、残ったものものを有効なKustomizeセットアップとして使用できます。まず、 generate-chart-upgrade-data.shスクリプトを実行し、アップグレードするHelmチャートのデータをKustomizeセットアップに読み込ませることを忘れないでください。

このワークフローの使用方法を理解するには、「概要」(29.4.3.3.1項「概要」)セクションと「アップグレード手順」(29.4.3.3.2項「アップグレード手順」)セクションを参照すると役立つでしょう。