Applies to SUSE Edge 3.6

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

このセクションでは、`downstream`クラスタの各部分において「Day 2」オペレーションを実行するための方法を説明します。

33.1 Fleet #

本セクションでは、Fleet (Chapter 6, Fleet)コンポーネントを使用して「Day 2」オペレーションを実行する方法について説明します。

本セクションでは、以下のトピックを扱います。

Section 33.1.1, “コンポーネント” - すべての「Day 2」オペレーションで使用されるデフォルトコンポーネント。
Section 33.1.2, “ユースケースの特定” - 使用されるFleetカスタムリソースの概要と、さまざまな「Day 2」オペレーションのユースケースへの適合性について説明します。
Section 33.1.3, “Day 2 ワークフロー” - Fleetを使用して「Day 2」オペレーションを実行するためのワークフローガイドを提供します。
Section 33.1.4, “OSのアップグレード” - Fleetを使用してOSアップグレードを実行する方法について説明します。
Section 33.1.5, “Kubernetesバージョンのアップグレード” - Fleetを使用してKubernetesバージョンのアップグレードを実行する方法について説明します。
Section 33.1.6, “Helmチャートのアップグレード” - Fleetを使用してHelmチャートのアップグレードを実行する方法について説明します。

33.1.1 コンポーネント #

以下に、Fleetを使用して「Day 2」オペレーションを正常に実行するために、`downstream`クラスター上にセットアップする必要があるデフォルトコンポーネントの説明を記載します。

33.1.1.1 System Upgrade Controller (SUC) #

Note

*Must*は、各ダウンストリームクラスターに必ずデプロイする必要があります。

*System Upgrade Controller*は、`Plan`と呼ばれるカスタムリソースを通じて提供される設定データに基づき、指定されたノードでタスクを実行する役割を担います。

*SUC*は、オペレーティングシステムおよびKubernetesディストリビューションのアップグレードに積極的に活用されています。

*SUC*コンポーネントの詳細およびEdgeスタックにおける位置付けについては、Chapter 18, System Upgrade Controllerを参照してください。

*SUC*のデプロイ方法については、まずユースケースを特定 (Section 33.1.2, “ユースケースの特定”)してから、System Upgrade Controllerのインストール - GitRepo (Section 18.2.1.1, “System Upgrade Controllerのインストール - GitRepo”)またはSystem Upgrade Controllerのインストール - Bundle (Section 18.2.1.2, “System Upgrade Controllerのインストール - Bundle”)を参照してください。

33.1.2 ユースケースの特定 #

Fleetは、KubernetesおよびHelmリソースの管理を可能にするために、2種類のカスタムリソースを使用します。

以下に、これらのリソースの目的と、「Day 2」オペレーションの文脈において最適なユースケースに関する情報を記載します。

33.1.2.1 GitRepo #

GitRepo`は、`Fleet`が`Bundles`を作成するためのGitリポジトリを表すFleet (Chapter 6, Fleet)リソースです。各 `Bundle は、GitRepo リソース内で定義された設定パスに基づいて作成されます。詳細については、 GitRepoマニュアルを参照してください。

「Day 2」運用のコンテキストでは、GitRepo リソースは通常、Fleet GitOps アプローチを利用する 非エアギャップ(された) 環境で SUC または SUC Plans をデプロイするために使用されます。

あるいは、ローカル git サーバーを介してリポジトリ設定をミラーリングすることを条件に、エアギャップ(された) 環境で SUC または SUC Plans をデプロイするために GitRepo リソースを使用することもできます。

33.1.2.2 バンドル #

Bundles は、ターゲットクラスターにデプロイされる raw Kubernetes リソースを保持します。通常、これらは GitRepo リソースから作成されますが、手動でデプロイできるユースケースもあります。詳細については、 Bundleマニュアルを参照してください。

「Day 2」運用のコンテキストでは、Bundle リソースは通常、ローカル GitOps 手順（例：ローカル git サーバー）を使用しない エアギャップ(された) 環境で SUC または SUC Plans をデプロイするために使用されます。

あるいは、ユースケースで GitOps ワークフロー（Git リポジトリの使用など）が許可されない場合は、非エアギャップ(された) 環境で SUC または SUC Plans をデプロイするために Bundle リソースを使用することもできます。

33.1.3 Day 2 ワークフロー #

以下は、downstream クラスターを特定の Edge リリースにアップグレードする際に従うべき「Day 2」ワークフローです。

OS upgrade (Section 33.1.4, “OSのアップグレード”)
Kubernetes version upgrade (Section 33.1.5, “Kubernetesバージョンのアップグレード”)
Helm チャートアップグレード (Section 33.1.6, “Helmチャートのアップグレード”)

33.1.4 OSのアップグレード #

このセクションでは、Chapter 6, FleetとChapter 18, System Upgrade Controllerを使用してオペレーティングシステムのアップグレードを実行する方法について説明します。

このセクションでは、以下のトピックについて説明します。

Section 33.1.4.1, “コンポーネント” - アップグレードプロセスで使用される追加コンポーネント。
Section 33.1.4.2, “概要” - アップグレードプロセスの概要。
Section 33.1.4.3, “要件” - アップグレードプロセスの要件。
Section 33.1.4.4, “OS アップグレード - SUC プランのデプロイメント” - アップグレードプロセスをトリガーする役割を担う`SUC plans`のデプロイ方法についての情報。

33.1.4.1 コンポーネント #

このセクションでは、`OS upgrade`プロセスがデフォルトの「Day 2」コンポーネント (Section 33.1.1, “コンポーネント”)の代わりに使用するカスタムコンポーネントについて説明します。

33.1.4.1.1 systemd.service #

特定のノードでのOSアップグレードは、systemd.serviceによって処理されます。

OSがEdgeのバージョン間で必要とするアップグレードの種類に応じて、異なるサービスが作成されます。

同じOSバージョンを必要とするEdgeバージョン（例：6.1）の場合、`os-pkg-update.service`が作成されます。これはトランザクション更新を使用して、通常のパッケージアップグレードを実行します。
OSバージョンの移行を必要とするEdgeバージョン（例：6.1 → 6.2）の場合、`os-migration.service`が作成されます。これはトランザクション更新を使用して、以下を実行します。
1. すべてのパッケージが最新であることを保証し、古いパッケージバージョンに関連する移行のエラーを軽減するための通常のパッケージアップグレード。
2. `zypper migration`コマンドを利用したOS移行。

上記のサービスは、OSアップグレードが必要なdownstreamクラスター上に配置する必要がある`SUC plan`を通じて、各ノードに配布されます。

33.1.4.2 概要 #

downstreamクラスターノードのオペレーティングシステムのアップグレードは、`Fleet`と`System Upgrade Controller (SUC)`を利用して行われます。

*Fleet*は、目的のクラスターに`SUC plans`をデプロイおよび管理するために使用されます。

Note

`SUC plans`は、特定のタスクを一連のノード上で実行するために`SUC`が従うべき手順を記述するカスタムリソースです。`SUC plan`がどのようなものかの例については、アップストリームリポジトリを参照してください。

OS SUC plans`は、特定のFleet ワークスペースに GitRepoまたは Bundleリソースをデプロイすることで、各クラスターに配布されます。Fleetはデプロイされた`GitRepo/Bundle`を取得し、その内容（`OS SUC plans）を目的のクラスターにデプロイします。

Note

`GitRepo/Bundle`リソースは常に`management cluster`にデプロイされます。`GitRepo`リソースと`Bundle`リソースのどちらを使用するかはユースケースによって異なります。詳細についてはSection 33.1.2, “ユースケースの特定”を確認してください。

`OS SUC plans`は次のワークフローを記述します。

OSアップグレードの前に、必ずノードをcordonしてください。
`control-plane`ノードの前に、必ず`worker`ノードをアップグレードしてください。
常に*one*ノードずつクラスターをアップグレードしてください。

`OS SUC plans`がデプロイされると、ワークフローは次のようになります。

SUCはデプロイされた`OS SUC plans`を調整し、*各ノード*に`Kubernetes Job`を作成します。
`Kubernetes Job`は、パッケージのアップグレードまたはOS移行のいずれかのためにsystemd.service (Section 33.1.4.1.1, “systemd.service”)を作成します。
作成された`systemd.service`は、特定のノードでOSアップグレードプロセスをトリガーします。
Important
OSアップグレードプロセスが完了すると、システムに更新を適用するために、対応するノードが`rebooted`されます。

上記の説明の図を以下に示します。

33.1.4.3 要件 #

全般:

SCC登録済みマシン - すべてのdownstreamクラスターノードは、それぞれの`https://scc.suse.com/`が目的のRPMリポジトリに正常に接続できるようにするために必要な`systemd.service`に登録されている必要があります。
Important
OSバージョンの移行（例: 6.1 → 6.2）を必要とするEdgeリリースの場合は、SCCキーが新しいバージョンへの移行をサポートしていることを確認してください。
SUCプランの許容設定がノードの許容設定と一致していることを確認してください - Kubernetesクラスターノードにカスタム*テイント*がある場合は、*SUCプラン*にそれらのテイントに対する許容設定を必ず追加してください。デフォルトでは、*SUCプラン*は*コントロールプレーン*ノードに対する許容設定のみを持っています。デフォルトの許容設定（tolerations）には以下が含まれます：
- CriticalAddonsOnly=true:NoExecute
- node-role.kubernetes.io/control-plane:NoSchedule
- node-role.kubernetes.io/etcd:NoExecute
  Note
  追加の許容設定は、各プランの .spec.tolerations セクションの下に追加する必要があります。OS アップグレードに関連する SUC プラン は、fleets/day2/system-upgrade-controller-plans/os-upgrade の下の suse-edge/fleet-examples リポジトリにあります。有効なリポジトリ release タグのプランを使用していることを確認してください。
  コントロールプレーン SUC プランのカスタム許容設定を定義する例は次のようになります：
  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 リポジトリはローカルにミラーリングし、systemd.service がそれらにアクセスできるようにする必要があります。これは、RMT または SUMA のいずれかを使用して実現できます。

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

Important

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

Remove any previously deployed SUC Plans related to older Edge release versions from the downstream cluster - 既存の GitRepo/Bundle ターゲット設定から目的のクラスターを削除するか、GitRepo/Bundle リソースを完全に削除することで実行できます。
Reuse the existing GitRepo/Bundle resource - リソースのリビジョンを、目的の suse-edge/fleet-examples リリースに適したフリートを保持する新しいタグに向けることで実行できます。

これは、古い Edge リリースバージョンの SUC Plans との競合を避けるために行われます。

ユーザーがアップグレードを試みる際に downstream クラスター上に既存の SUC Plans が存在する場合、次のようなフリートエラーが表示されます：

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..

Section 33.1.4.2, “概要” で述べたように、OS のアップグレードは、以下のいずれかの方法で目的のクラスターに SUC plans を送信することによって行われます：

Fleet GitRepo リソース - Section 33.1.4.4.1, “SUC プランのデプロイメント - GitRepo リソース”。
Fleet Bundle リソース - Section 33.1.4.4.2, “SUCプランのデプロイメント - Bundleリソース”。

どのリソースを使用すべきかを判断するには、Section 33.1.2, “ユースケースの特定” を参照してください。

サードパーティの GitOps ツールから OS SUC plans をデプロイしたいユースケースについては、Section 33.1.4.4.3, “SUCプランのデプロイ - サードパーティのGitOpsワークフロー” を参照してください。

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

必要な OS SUC plans を送信する GitRepo リソースは、以下のいずれかの方法でデプロイできます：

Rancher UI - Section 33.1.4.4.1.1, “GitRepoの作成 - Rancher UI” を通じて（`Rancher`が利用可能な場合）。
リソースを手動でデプロイ (Section 33.1.4.4.1.2, “GitRepoの作成 - 手動”) して、management cluster に適用します。

デプロイ後、ターゲットクラスターのノードのOSアップグレードプロセスを監視するには、Section 18.3, “System Upgrade Controllerプランの監視” を参照してください。

33.1.4.4.1.1 GitRepoの作成 - Rancher UI #

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

Edgeチームは、すぐに使用できる Fleet を維持管理しています。環境によっては、このFleetを直接使用することも、テンプレートとして使用することもできます。

Important

必ず有効な Edge release タグからこのFleetを使用してください。

Fleetが提供する SUC plans にカスタム変更を含める必要がないユースケースでは、ユーザーは suse-edge/fleet-examples リポジトリから os-upgrade Fleetを直接参照できます。

カスタム変更が必要な場合（カスタムテイントの追加など）、ユーザーは別のリポジトリから os-upgrade Fleetを参照し、必要に応じてSUCプランに変更を追加できるようにする必要があります。

GitRepo が suse-edge/fleet-examples リポジトリのFleetを使用するように構成する方法の例は、こちらで確認できます。

33.1.4.4.1.2 GitRepoの作成 - 手動 #

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

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

GitRepo 設定を編集し、spec.targets の下に目的のターゲットリストを指定します。デフォルトでは、GitRepo の suse-edge/fleet-examples リソースは、どのダウンストリームクラスターにも マッピングされていません。
- すべてのクラスターに一致させるには、デフォルトの GitRepo ターゲット を次のように変更します：
```
spec:
  targets:
  - clusterSelector: {}
```
- あるいは、より詳細なクラスター選択が必要な場合は、ダウンストリームクラスターへのマッピングを参照してください。
`management 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.6.1  0/0

33.1.4.4.2 SUCプランのデプロイメント - Bundleリソース #

必要なを配布する*Bundle*`OS SUC Plans`リソースは、以下のいずれかの方法でデプロイできます。

Rancher UI - Section 33.1.4.4.2.1, “Bundleの作成 - Rancher UI” を通じて（`Rancher`が利用可能な場合）。
リソースを手動でデプロイ (Section 33.1.4.4.2.2, “バンドルの作成 - 手動”) して、management cluster に適用します。

33.1.4.4.2.1 Bundleの作成 - Rancher UI #

Edgeチームは、以下の手順で使用できるすぐに使えるbundleを管理しています。

Important

必ず有効なEdge releaseタグのこのBundleを使用してください。

RancherのUIからBundleを作成するには：

左上隅で、*☰ → Continuous Delivery*をクリックします。
Advanced > *Bundles*に移動します。
*Create from YAML*を選択します。
ここから、以下のいずれかの方法でBundleを作成できます。
Note
Bundleが配布する`SUC plans`にカスタム変更を含める必要があるユースケースがあるかもしれません（例：カスタムのtolerationを追加する場合など）。以下の手順で生成されるBundleに、それらの変更を必ず含めてください。
1. `suse-edge/fleet-examples`からbundle contentを手動でコピーし、*Create from YAML*ページに貼り付けます。
2. 目的のreleaseタグからsuse-edge/fleet-examplesリポジトリをクローンし、*Create from YAML*ページの*Read from File*オプションを選択します。そこからBundleの場所（bundles/day2/system-upgrade-controller-plans/os-upgrade）に移動し、Bundleファイルを選択します。これにより、*Create from YAML*ページにBundleの内容が自動的に入力されます。
`Bundle`の*target*クラスターを変更します。
- すべてのダウンストリームクラスターに一致させるには、デフォルトのBundle `.spec.targets`を以下のように変更します。
```
spec:
  targets:
  - clusterSelector: {}
```
- より詳細なダウンストリームクラスターのマッピングについては、ダウンストリームクラスターへのマッピングを参照してください。
［作成］を選択します。

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

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

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

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

33.1.4.4.3 SUCプランのデプロイ - サードパーティのGitOpsワークフロー #

ユーザーが`OS SUC plans`を独自のサードパーティGitOpsワークフロー（例: Flux）に組み込みたいというユースケースがあるかもしれません。

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

その後、リソースは`fleets/day2/system-upgrade-controller-plans/os-upgrade`にあります。ここで：

`plan-control-plane.yaml`は、*コントロールプレーン*ノード用のSUCプランリソースです。
`plan-worker.yaml`は、*ワーカー*ノード用のSUCプランリソースです。
`secret.yaml`は、systemd.service (Section 33.1.4.1.1, “systemd.service”)を作成する役割を担う`upgrade.sh`スクリプトを含むシークレットです。
`config-map.yaml`は、`upgrade.sh`スクリプトによって使用される設定を保持するConfigMapです。

Important

これらの`Plan`リソースは`System Upgrade Controller`によって解釈されるため、アップグレードする各ダウンストリームクラスターに展開する必要があります。SUCの展開に関する情報については、Section 18.2, “System Upgrade Controllerのインストール”を参照してください。

OSアップグレード用の*SUC Plans*を展開するためにGitOpsワークフローをどのように使用できるかをより深く理解するには、overview (Section 33.1.4.2, “概要”)を参照すると役立ちます。

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

Important

このセクションでは、NOT Rancher (Chapter 4, Rancher)インスタンスを通じて作成されたダウンストリームクラスターのKubernetesアップグレードについて説明します。`Rancher`で作成されたクラスターのKubernetesバージョンをアップグレードする方法については、Kubernetesのアップグレードとロールバックを参照してください。

このセクションでは、Chapter 6, FleetとChapter 18, System Upgrade Controllerを使用してKubernetesのアップグレードを実行する方法について説明します。

このセクションでは、以下のトピックについて説明します。

Section 33.1.5.1, “コンポーネント” - アップグレードプロセスで使用される追加コンポーネント。
Section 33.1.5.2, “概要” - アップグレードプロセスの概要。
Section 33.1.5.3, “要件” - アップグレードプロセスの要件。
Section 33.1.5.4, “K8sアップグレード - SUCプランのデプロイメント” - アップグレードプロセスをトリガーする役割を担う`SUC plans`のデプロイ方法に関する情報。

33.1.5.1 コンポーネント #

このセクションでは、デフォルトの「Day 2」コンポーネント (Section 33.1.1, “コンポーネント”)に加えて`K8s upgrade`プロセスが使用するカスタムコンポーネントについて説明します。

33.1.5.1.1 rke2-upgrade #

特定のノードのRKE2バージョンをアップグレードするためのコンテナイメージ。

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

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

33.1.5.1.2 k3s-upgrade #

特定のノードのK3sバージョンをアップグレードするためのコンテナイメージ。

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

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

33.1.5.2 概要 #

downstreamクラスターノードのKubernetesディストリビューションのアップグレードは、`Fleet`と`System Upgrade Controller (SUC)`を利用して行われます。

`Fleet`は、目的のクラスターに`SUC plans`をデプロイおよび管理するために使用されます。

Note

`SUC plans`は、特定のタスクを一連のノードで実行するために*SUC*が従うべき手順を記述したカスタムリソースです。`SUC plan`の例については、アップストリームリポジトリを参照してください。

K8s SUC plans`は、 GitRepoまたは Bundleリソースを特定のFleet workspaceにデプロイすることで、各クラスターにデプロイされます。Fleetはデプロイされた`GitRepo/Bundle`を取得し、その内容（`K8s SUC plans）を目的のクラスター（複数可）にデプロイします。

Note

`GitRepo/Bundle`リソースは常に`management cluster`にデプロイされます。`GitRepo`リソースと`Bundle`リソースのどちらを使用するかはユースケースによって異なります。詳細についてはSection 33.1.2, “ユースケースの特定”を参照してください。

`K8s SUC plans`は以下のワークフローを記述します。

K8sのアップグレード前には、必ずノードをコードンしてください。
常に`control-plane`ノードを`worker`ノードより先にアップグレードしてください。
常に`control-plane`ノードは*一つ*ずつ、`worker`ノードは*二つ*ずつアップグレードしてください。

`K8s SUC plans`がデプロイされたら、ワークフローは次のようになります。

SUCはデプロイされた`K8s SUC plans`を同期し、*各ノード*に`Kubernetes Job`を作成します。
Kubernetesのディストリビューションに応じて、Jobはrke2-upgrade (Section 33.1.5.1.1, “rke2-upgrade”)またはk3s-upgrade (Section 33.1.5.1.2, “k3s-upgrade”)コンテナイメージのいずれかを実行するPodを作成します。
作成されたPodは、以下のワークフローに従います。
1. ノード上の既存の`rke2/k3s`バイナリを、`rke2-upgrade/k3s-upgrade`イメージから取得したものに置き換えます。
2. 実行中の`rke2/k3s`プロセスを停止します。
`rke2/k3s`プロセスを停止すると再起動がトリガーされ、更新されたバイナリを実行する新しいプロセスが起動し、その結果、Kubernetesディストリビューションはアップグレードされたバージョンになります。

上記の説明の図を以下に示します。

33.1.5.3 要件 #

Kubernetesディストリビューションをバックアップしてください:
1. *RKE2クラスター*については、RKE2 バックアップおよびリストアのドキュメントを参照してください。
2. *K3sクラスター*については、K3s バックアップおよびリストアのドキュメントを参照してください。
SUCプランのトレラレーションがノードのトレラレーションと一致していることを確認しましょう - Kubernetesクラスターのノードにカスタム*テイント*がある場合は、*SUCプラン*でそれらのテイントに対するトレラレーションを必ず追加してください。デフォルトでは、*SUC Plans*には*control-plane*ノードに対するトレラレーションのみが含まれています。デフォルトのトレラレーションには以下が含まれます：
- CriticalAddonsOnly=true:NoExecute
- node-role.kubernetes.io/control-plane:NoSchedule
- node-role.kubernetes.io/etcd:NoExecute
  Note
  追加のトレラレーションは、各プランの`.spec.tolerations`セクションの下に追加する必要があります。Kubernetesバージョンアップグレードに関連する*SUC Plans*は、suse-edge/fleet-examplesリポジトリの以下にあります。
  *RKE2*の場合 - fleets/day2/system-upgrade-controller-plans/rke2-upgrade
  *K3s*の場合 - fleets/day2/system-upgrade-controller-plans/k3s-upgrade
  有効なリポジトリreleaseタグのプランを使用していることを確認してください。
  RKE2 control-plane SUCプランのカスタムトレラレーションを定義する例は、次のようになります。
  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" ...

33.1.5.4 K8sアップグレード - SUCプランのデプロイメント #

Important

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

Remove any previously deployed SUC Plans related to older Edge release versions from the downstream cluster - 既存の`GitRepo/Bundle`target configurationから目的のクラスターを削除するか、`GitRepo/Bundle`リソース自体を削除することで実行できます。
Reuse the existing GitRepo/Bundle resource - リソースのリビジョンを、目的の`suse-edge/fleet-examples`releaseに適したフリートを保持する新しいタグに向けることで実行できます。

これは、古いEdgeリリースバージョンの`SUC Plans`との競合を避けるために行われます。

ユーザーがアップグレードを試みた際に、downstreamクラスター上に既存の`SUC Plans`が存在する場合、以下のフリートエラーが表示されます。

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..

Section 33.1.5.2, “概要”で述べたように、Kubernetesのアップグレードは、以下のいずれかの方法で目的のクラスターに`SUC plans`を配布することによって行われます。

Fleet GitRepo リソース (Section 33.1.5.4.1, “SUCプランのデプロイ - GitRepoリソース”)
Fleet Bundle リソース (Section 33.1.5.4.2, “SUCプランのデプロイ - バンドルリソース”)

どのリソースを使用すべきかを判断するには、Section 33.1.2, “ユースケースの特定”を参照してください。

サードパーティのGitOpsツールから`K8s SUC plans`をデプロイしたいユースケースについては、Section 33.1.5.4.3, “SUC プランの展開 - サードパーティの GitOps ワークフロー”を参照してください。

33.1.5.4.1 SUCプランのデプロイ - GitRepoリソース #

必要な`K8s SUC plans`を配布する*GitRepo*リソースは、以下のいずれかの方法でデプロイできます。

Rancher UI - Section 33.1.5.4.1.1, “GitRepoの作成 - Rancher UI” を通じて（`Rancher`が利用可能な場合）。
management cluster にリソースを手動でデプロイ (Section 33.1.5.4.1.2, “GitRepoの作成 - 手動”) することによって。

デプロイ後、ターゲットクラスターのノードのKubernetesアップグレードプロセスを監視するには、Section 18.3, “System Upgrade Controllerプランの監視” を参照してください。

33.1.5.4.1.1 GitRepoの作成 - Rancher UI #

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

Edgeチームは、RKE2 および K3s のKubernetesディストリビューション向けに、すぐに使用できるフリート（Fleet）を維持しています。環境に応じて、このフリートを直接使用することも、テンプレートとして使用することもできます。

Important

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

これらのフリートに同梱されている SUC plans にカスタム変更を含める必要がないユースケースでは、ユーザーは suse-edge/fleet-examples リポジトリから直接フリートを参照できます。

カスタム変更が必要な場合（カスタムTolerationを追加する場合など）、ユーザーは別のリポジトリからフリートを参照する必要があります。これにより、必要に応じてSUCプランに変更を加えることができます。

suse-edge/fleet-examples リポジトリのフリートを使用した GitRepo リソースの設定例：

33.1.5.4.1.2 GitRepoの作成 - 手動 #

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

RKE2 クラスターの場合：

curl -o rke2-upgrade-gitrepo.yaml https://raw.githubusercontent.com/suse-edge/fleet-examples/refs/tags/release-3.6.1/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.6.1/gitrepos/day2/k3s-upgrade-gitrepo.yaml

GitRepo 設定を編集し、spec.targets の下に目的のターゲットリストを指定します。デフォルトでは、GitRepo の suse-edge/fleet-examples リソースは、どのダウンストリームクラスターにも NOT マッピングされていません。
- すべてのクラスターに一致させるには、デフォルトの GitRepo target を次のように変更します：
```
spec:
  targets:
  - clusterSelector: {}
```
- あるいは、より詳細なクラスター選択が必要な場合は、Mapping to Downstream Clustersを参照してください。

*GitRepo*リソースを`management cluster`に適用します。

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

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

作成された*GitRepo*リソースを`fleet-default`名前空間の下で表示します。

# 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   fleet-default   0/0
rke2-upgrade   https://github.com/suse-edge/fleet-examples.git   fleet-default   0/0

33.1.5.4.2 SUCプランのデプロイ - バンドルリソース #

必要な`Kubernetes upgrade SUC Plans`を出荷する*Bundle*リソースは、以下のいずれかの方法でデプロイできます。

Rancher UI - Section 33.1.5.4.2.1, “バンドルの作成 - Rancher UI” を通じて（`Rancher`が利用可能な場合）。
management cluster にリソースを手動でデプロイ (Section 33.1.5.4.2.2, “バンドルの作成 - 手動”) することによって。

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

Edgeチームは、rke2およびk3sの両方のKubernetesディストリビューションですぐに使用できるバンドルを維持管理しています。環境に応じて、これらのバンドルを直接使用することも、テンプレートとして使用することもできます。

Important

必ず有効なEdge releaseタグからこのバンドルを使用してください。

RancherのUIからバンドルを作成するには、以下の手順を実行します。

左上隅にある*☰ → Continuous Delivery*をクリックします。
Advanced > *Bundles*に移動します。
*Create from YAML*を選択します。
ここから、以下のいずれかの方法でバンドルを作成できます。
Note
バンドルが出荷する`SUC plans`にカスタム変更を含める必要があるユースケースがあるかもしれません（例：カスタムのtolerationsを追加する場合など）。以下の手順で生成されるバンドルに、これらの変更が含まれていることを確認してください。
1. `suse-edge/fleet-examples`からRKE2またはK3sのバンドルコンテンツを、*Create from YAML*ページに手動でコピーします。
2. 目的のreleaseタグからsuse-edge/fleet-examplesリポジトリをクローンし、*Create from 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*ページにバンドルコンテンツが自動入力されます。
`Bundle`の*target*クラスターを変更します。
- すべてのダウンストリームクラスターと一致させるには、デフォルトのバンドル`.spec.targets`を以下のように変更します。
```
spec:
  targets:
  - clusterSelector: {}
```
- より詳細なダウンストリームクラスターのマッピングについては、Mapping to Downstream Clustersを参照してください。
*Create*を選択します。

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

*Bundle*リソースをプルします。

RKE2 クラスターの場合：

curl -o rke2-plan-bundle.yaml https://raw.githubusercontent.com/suse-edge/fleet-examples/refs/tags/release-3.6.1/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.6.1/bundles/day2/system-upgrade-controller-plans/k3s-upgrade/plan-bundle.yaml

`Bundle`の*target*設定を編集し、`spec.targets`の下に目的のターゲットリストを指定します。デフォルトでは、`Bundle`の`suse-edge/fleet-examples`リソースは、どのダウンストリームクラスターにも NOT マッピングされていません。
- すべてのクラスターに一致させるには、デフォルトの Bundle target を次のように変更します：
```
spec:
  targets:
  - clusterSelector: {}
```
- あるいは、より詳細なクラスター選択が必要な場合は、Mapping to Downstream Clustersを参照してください。

`management cluster`に*Bundle*リソースを適用します。

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

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

fleet-default 名前空間の下で作成された Bundle リソースを表示します。

# 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

33.1.5.4.3 SUC プランの展開 - サードパーティの GitOps ワークフロー #

ユーザーが Kubernetes upgrade SUC plans を独自のサードパーティ GitOps ワークフロー (例: Flux) に組み込みたいというユースケースがあるかもしれません。

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

その後、リソースは以下から入手できます。

RKE2 クラスターのアップグレードの場合:
- control-plane ノード用 - fleets/day2/system-upgrade-controller-plans/rke2-upgrade/plan-control-plane.yaml
- worker ノード用 - 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
- worker ノード用 - fleets/day2/system-upgrade-controller-plans/k3s-upgrade/plan-worker.yaml

Important

これらの Plan リソースは System Upgrade Controller によって解釈され、アップグレードする各ダウンストリームクラスターに展開する必要があります。SUC 展開に関する情報については、Section 18.2, “System Upgrade Controllerのインストール”を参照してください。

Kubernetes バージョンアップグレードのために SUC Plans をデプロイする GitOps ワークフローをより深く理解するには、Fleet を用いた更新手順の overview (Section 33.1.5.2, “概要”) を確認することが有益です。

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

このセクションでは、次の部分について説明します。

Section 33.1.6.1, “エアギャップ(された)環境の準備” - Edge関連のOCIチャートおよびイメージをプライベートレジストリに配布する方法に関する情報が記載されています。
Section 33.1.6.2, “アップグレード手順” - さまざまなHelmチャートアップグレードのユースケースと、そのアップグレード手順に関する情報が記載されています。

33.1.6.1 エアギャップ(された)環境の準備 #

33.1.6.1.1 HelmチャートFleetにアクセスできることを確認してください。 #

環境のサポート状況に応じて、次のいずれかのオプションを選択できます。

`management cluster`からアクセス可能なローカルGitサーバーで、チャートのFleetリソースをホストします。
FleetのCLIを使用して、HelmチャートをBundleに変換します。これにより、直接使用できるようになり、どこかでホストする必要がなくなります。FleetのCLIは、リリースページから取得できます。Macユーザーの場合は、fleet-cli Homebrew Formulaeが用意されています。

33.1.6.1.2 Edgeリリースバージョンに必要なアセットを見つける #

「Day 2」のリリースページに移動し、チャートのアップグレード先となるEdgeリリースを見つけて、*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リリースに関連するイメージのリストが含まれています。

33.1.6.1.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`という名前のロード可能なアーカイブが作成されます。
Note
`-i|--images`オプションが指定されている場合、アーカイブの名前が異なることがあります。
このアーカイブを*エアギャップ(された)*マシンにコピーします：
```
scp edge-images.tar.gz <user>@<machine_ip>:/path
```

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

33.1.6.1.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
```
Note
これにより、edge-images.tar.gz`からすべてのイメージがロードされ、タグが付け直されて、--registry`オプションで指定されたレジストリにプッシュされます。

33.1.6.1.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チャートイメージをプライベートレジストリにロードします：
Note
このスクリプトは、helm CLIが環境にプレインストールされていることを前提としています。Helmのインストール手順については、Installing Helmを参照してください。
```
./edge-load-oci-artefacts.sh --archive-directory edge-release-oci-tgz-<date> --registry <REGISTRY.YOURDOMAIN.COM:PORT> --source-registry registry.suse.com
```

33.1.6.1.7 Kubernetesディストリビューションでプライベートレジストリを設定します。 #

RKE2については、Private Registry Configurationを参照してください。

K3sについては、Private Registry Configurationを参照してください。

33.1.6.2 アップグレード手順 #

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

Important

手動でデプロイされたHelmチャートは、確実にアップグレードすることはできません。Section 33.1.6.2.1, “新しいクラスターがあり、Edge Helmチャートをデプロイおよび管理したい場合”メソッドを使用してHelmチャートを再デプロイすることをお勧めします。

33.1.6.2.1 新しいクラスターがあり、Edge Helmチャートをデプロイおよび管理したい場合 #

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

33.1.6.2.1.1 チャートのFleetリソースを準備する #

使用するEdge releaseタグから、チャートのFleetリソースを取得します。
HelmチャートのFleet（fleets/day2/chart-templates/<chart>）に移動します。
GitOpsワークフローを使用する予定がある場合は、チャートのFleetディレクトリを、GitOpsを実行するGitリポジトリにコピーします。
必要に応じて、Helmチャートで*values*の設定が必要な場合は、コピーしたディレクトリ内の`.helm.values`ファイルにある`fleet.yaml`設定を編集してください。
必要に応じて、環境に合わせてチャートのFleetにリソースを追加する必要があるユースケースも考えられます。Fleetディレクトリを拡張する方法については、Git Repository Contentsを参照してください。

Note

場合によっては、FleetがHelm操作に使用するデフォルトのタイムアウトでは不十分であり、次のようなエラーが発生することがあります。

failed pre-install: context deadline exceeded

そのような場合は、`fleet.yaml`ファイルの`helm`設定の下にtimeoutSecondsプロパティを追加してください。

*例*として、`longhorn`ヘルムチャートの場合は次のようになります：

ユーザーGitリポジトリの構造：

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

`fleet.yaml`ユーザー`Longhorn`データが含まれるコンテンツ：

defaultNamespace: longhorn-system

helm:
  # timeoutSeconds: 10
  releaseName: "longhorn"
  chart: "longhorn"
  repo: "https://charts.rancher.io/"
  version: "1.11.2"
  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"}

Note

これらは、`longhorn`チャートに対するカスタム設定を説明するために使用される単なる例の値です。これらは`longhorn`チャートのデプロイメントガイドラインとして扱うべきでは*ありません*。

33.1.6.2.1.2 チャートのFleetをデプロイする #

GitRepo (Section 33.1.6.2.1.2.1, “GitRepo”)またはBundle (Section 33.1.6.2.1.2.2, “バンドル”)のいずれかを使用して、チャートのFleetをデプロイできます。

Note

Fleetのデプロイ中に`Modified`メッセージが表示された場合は、対応する`comparePatches`エントリをFleetの`diff`セクションに必ず追加してください。詳細については、変更されたGitRepoを無視するためのDiffの生成を参照してください。

33.1.6.2.1.2.1 GitRepo #

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

`GitRepo`リソースは、Rancher UIを通じてデプロイするか、または手動で`management cluster`にデプロイすることもできます。

手動*デプロイ用の*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: {}

33.1.6.2.1.2.2 バンドル #

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

Bundle`は、Rancher UI（`Continuous Delivery → Advanced → Bundles → Create from YAML）を通じて、または正しいFleetネームスペースに`Bundle`リソースを手動でデプロイすることでデプロイできます。Fleetネームスペースの詳細については、アップストリームのドキュメントを参照してください。

Edge Helmチャート用の`Bundles`は、FleetのHelmチャートをバンドルに変換するアプローチを利用して作成できます。

以下に、longhornおよびlonghorn-crd HelmチャートFleetテンプレートから`Bundle`リソースを作成し、このバンドルを`management cluster`に手動でデプロイする方法の例を示します。

Note

ワークフローを説明するために、以下の例ではsuse-edge/fleet-examples ディレクトリ構造を使用しています。

longhornチャートFleetテンプレートに移動します：
```
cd fleets/day2/chart-templates/longhorn/longhorn
```
FleetがHelmチャートをデプロイすべきクラスターを指示する`targets.yaml`ファイルを作成します。
```
cat > targets.yaml <<EOF
targets:
# Matches all downstream clusters
- clusterSelector: {}
EOF
```
より詳細なダウンストリームクラスターの選択については、ダウンストリームクラスターへのマッピングを参照してください。
fleet-cliを使用して、Longhorn HelmチャートFleetをBundleリソースに変換します。
Note
FleetのCLIは、リリース*アセット*ページ（fleet-linux-amd64）から取得できます。
Macユーザー向けには、fleet-cliのHomebrew Formulaeが用意されています。
```
fleet apply --compress --targets-file=targets.yaml -n fleet-default -o - longhorn-bundle > longhorn-bundle.yaml
```
longhorn-crdチャートのFleetテンプレートに移動します。
```
cd fleets/day2/chart-templates/longhorn/longhorn-crd
```
FleetがHelmチャートをデプロイすべきクラスターを指示する`targets.yaml`ファイルを作成します。
```
cat > targets.yaml <<EOF
targets:
# Matches all downstream clusters
- clusterSelector: {}
EOF
```

fleet-cliを使用して、Longhorn CRD HelmチャートFleetをBundleリソースに変換します。

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`ファイルを`management cluster`にデプロイします。
```
kubectl apply -f longhorn-crd-bundle.yaml
kubectl apply -f longhorn-bundle.yaml
```

これらの手順に従うことで、指定されたすべてのdownstreamクラスターに`SUSE Storage`が確実にデプロイされます。

33.1.6.2.1.3 デプロイされたHelmチャートを管理する #

Fleetでデプロイした後、HelmチャートのアップグレードについてはSection 33.1.6.2.2, “Fleetで管理されているHelmチャートをアップグレードしたい”を参照してください。

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

目的のEdgeリリースと互換性を持たせるために、チャートをアップグレードする必要があるバージョンを決定します。EdgeリリースごとのHelmチャートバージョンは、リリースノート (Chapter 41, リリースノート)から確認できます。
Fleetで監視されているGitリポジトリで、Helmチャートの`fleet.yaml`ファイルを編集し、リリースノート (Chapter 41, リリースノート)から正しいチャートの*バージョン*と*リポジトリ*を指定します。
変更をコミットしてリポジトリにプッシュすると、目的のHelmチャートのアップグレードがトリガーされます。

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

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

`EIB`経由でデプロイされたHelmチャートが確実にアップグレードされるように、ユーザーはそれぞれの`HelmChart`リソースに対してアップグレードを行う必要があります。

以下の情報をご覧ください。

アップグレードプロセスの一般的な概要 (Section 33.1.6.2.3.1, “概要”)。
必要なアップグレード手順 (Section 33.1.6.2.3.2, “アップグレード手順”)。
説明した方法を使用してLonghornチャートのアップグレードを示す例 (Section 33.1.6.2.3.3, “例”)。
別のGitOpsツール (Section 33.1.6.2.3.4, “サードパーティのGitOpsツールを使用したHelmチャートのアップグレード”)でアップグレードプロセスを使用する方法。

33.1.6.2.3.1 概要 #

`EIB`経由でデプロイされたHelmチャートは、eib-charts-upgraderと呼ばれる`fleet`を通じてアップグレードされます。

この`fleet`は、*ユーザー提供*のデータを処理して、特定のHelmChartリソースのセットを*更新*します。

これらのリソースを更新するとhelm-controllerがトリガーされ、変更された`HelmChart`リソースに関連付けられたHelmチャートが*アップグレード*されます。

ユーザーが行う必要があるのは、以下の操作のみです。

アップグレードが必要な各Helmチャートのアーカイブをローカルでプルします。
これらのアーカイブをgenerate-chart-upgrade-data.sh`generate-chart-upgrade-data.sh`スクリプトに渡します。このスクリプトは、これらのアーカイブのデータを`eib-charts-upgrader`Fleetに含めます。
`eib-charts-upgrader`Fleetを`management cluster`にデプロイします。これは、`GitRepo`または`Bundle`リソースのいずれかを通じて行われます。

デプロイされると、`eib-charts-upgrader`はFleetの助けを借りて、そのリソースを目的のdownstreamクラスターに配布します。

これらのリソースには以下が含まれます。

*ユーザー提供*のHelmチャートデータを保持する`Secrets`のセット。
前述の`Secrets`をマウントし、それに基づいて対応するHelmChartリソースをパッチする`Pod`をデプロイする`Kubernetes Job`。

前述の通り、これにより`helm-controller`がトリガーされ、実際のHelmチャートのアップグレードが実行されます。

上記の説明の図を以下に示します。

33.1.6.2.3.2 アップグレード手順 #

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

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

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`スクリプトを実行します：
```
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
```
--archive-dir`ディレクトリ内の各チャートアーカイブに対して、スクリプトはチャートのアップグレードデータを含む`Kubernetes Secret YAML`ファイルを生成し、--fleet-path`で指定されたFleetの`base/secrets`ディレクトリに保存します。
`generate-chart-upgrade-data.sh`スクリプトは、生成された`Kubernetes Secret YAML`ファイルがFleetによってデプロイされたワークロードで正しく使用されるように、Fleetに追加の変更を適用します。
Important
ユーザーは、`generate-chart-upgrade-data.sh`スクリプトが生成するものに対して変更を加えるべきではありません。

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

GitOpsをサポートしている環境（例：エアギャップ環境ではない、またはエアギャップ環境だがローカルGitサーバーのサポートが許可されている場合）の場合：
1. GitOpsに使用するリポジトリに`fleets/day2/eib-charts-upgrader` Fleetをコピーします。
  Note
  `generate-chart-upgrade-data.sh`スクリプトによって行われた変更がFleetに含まれていることを確認してください。
2. eib-charts-upgrader Fleetのすべてのリソースを配送するために使用される`GitRepo`リソースを設定します。
  1. Rancher UIを通じた`GitRepo`の設定とデプロイについては、Rancher UIでのFleetへのアクセスを参照してください。
  2. `GitRepo`の手動設定とデプロイについては、デプロイの作成を参照してください。
GitOpsをサポートしていない環境（例：エアギャップで、ローカルGitサーバーの使用が許可されていない場合）の場合：
1. rancher/fleet`のリリースページから`fleet-cli`バイナリをダウンロードします（Linuxの場合は`fleet-linux-amd64）。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:
# To match all downstream clusters
- clusterSelector: {}
EOF
```
  ターゲットクラスターのマッピング方法については、アップストリームドキュメントを参照してください。
4. fleet-cli を使用して、Fleet を Bundle リソースに変換します。
```
fleet apply --compress --targets-file=targets.yaml -n fleet-default -o - eib-charts-upgrade > bundle.yaml
```
  これにより、eib-charts-upgrader Fleet からのすべてのテンプレート化されたリソースを保持する Bundle (bundle.yaml) が作成されます。
  fleet apply コマンドの詳細については、「fleet apply」を参照してください。
  Fleet を Bundle に変換する方法の詳細については、「Convert a Helm Chart into a Bundle」を参照してください。
5. Bundle をデプロイする。これには、次の2つの方法があります。
  1. Rancher の UI を使用する場合 - 継続的デリバリ → Advanced → Bundles → Create from YAML に移動し、bundle.yaml の内容を貼り付けるか、Read from File オプションをクリックしてファイル自体を渡します。
  2. 手動 - bundle.yaml ファイルを`management cluster`内にデプロイします。

これらの手順を実行すると、GitRepo/Bundle リソースが正常にデプロイされます。このリソースは Fleet によって取得され、その内容はユーザーが前の手順で指定したターゲットクラスターにデプロイされる。この処理の概要については、「Section 33.1.6.2.3.1, “概要”」を参照してください。

アップグレードの処理を追跡する方法については、Section 33.1.6.2.3.3, “例” を参照してください。

Important

チャートのアップグレードが正常に確認できたら、Bundle/GitRepo リソースを削除する。

これにより、不要になったアップグレードリソースを downstream クラスターから削除することで、将来的なバージョン競合の発生を防ぐことができます。

33.1.6.2.3.3 例 #

Note

以下の例は、EIB を介してデプロイされた Helm チャートを downstream クラスター上で別のバージョンにアップグレードする方法を示しています。この例で使用されているバージョンは*推奨されているものではありません*のでご注意ください。Edge リリース固有の推奨バージョンについては、「リリースノート (Chapter 41, リリースノート)」を参照してください。

使用事例:

`doc-example`という名前のクラスターで、Longhornの古いバージョンが実行されています。

クラスターはEIBを通じてデプロイされており、次のイメージ定義_snippet_を使用しています。

kubernetes:
  helm:
    charts:
    - name: longhorn-crd
      repositoryName: rancher-charts
      targetNamespace: longhorn-system
      createNamespace: true
      version: 104.2.0+up1.7.1
      installationNamespace: kube-system
    - name: longhorn
      repositoryName: rancher-charts
      targetNamespace: longhorn-system
      createNamespace: true
      version: 104.2.0+up1.7.1
      installationNamespace: kube-system
    repositories:
    - name: rancher-charts
      url: https://charts.rancher.io/
...

SUSE Storage`は、Edge 3.6リリースと互換性のあるバージョンにアップグレードする必要があります。つまり、1.11.2`にアップグレードする必要があります。
`management cluster`の管理を担当する`doc-example`は*エアギャップ(された)*であり、ローカルGitサーバーのサポートがなく、Rancherが正常にセットアップされていると想定されます。

アップグレード手順 (Section 33.1.6.2.3.2, “アップグレード手順”)に従ってください。

`release-3.6.1`タグから`suse-edge/fleet-example`リポジトリをクローンします。
```
git clone -b release-3.6.1 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.11.2 chart archive
helm pull oci://dp.apps.rancher.io/charts/suse-storage --version 1.11.2

`archives`ディレクトリの外で、`suse-edge/fleet-examples`リリースtagから`generate-chart-upgrade-data.sh`スクリプトをダウンロードします。

ディレクトリのセットアップは次のようになります。

.
├── archives
│   └── longhorn-1.11.2.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-1.11.2.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-VERSION.yaml - secret created by the generate-chart-upgrade-data.sh script
│   │   │   │   │       └── longhorn-crd-VERSION.yaml - secret created by the generate-chart-upgrade-data.sh script
│   │   │   │   ├── fleet.yaml
│   │   │   │   └── kustomization.yaml
│   │   │   └── ...
│   └── ...
└── generate-chart-upgrade-data.sh

gitで変更されたファイルは次のようになります。

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   fleets/day2/eib-charts-upgrader/base/patches/job-patch.yaml
    modified:   fleets/day2/eib-charts-upgrader/base/secrets/kustomization.yaml

Untracked files:
  (use "git add <file>..." to include in what will be committed)
    fleets/day2/eib-charts-upgrader/base/secrets/longhorn-VERSION.yaml
    fleets/day2/eib-charts-upgrader/base/secrets/longhorn-crd-VERSION.yaml

Bundle Fleet用の`eib-charts-upgrader`を作成します。
1. まず、Fleet自体に移動します。
```
cd ./fleet-examples/fleets/day2/eib-charts-upgrader
```
2. 次に、`targets.yaml`ファイルを作成します。
```
cat > targets.yaml <<EOF
targets:
- clusterName: doc-example
EOF
```
3. 次に、`fleet-cli`バイナリを使用してFleetをBundleに変換します。
```
fleet apply --compress --targets-file=targets.yaml -n fleet-default -o - eib-charts-upgrade > bundle.yaml
```
4. 次に、`bundle.yaml`マシン上の`management cluster`を転送します。
Rancher UIからBundleをデプロイします：
Figure 33.1: Rancher UIからBundleをデプロイする #

ここから、*Read from File*を選択し、システム上の`bundle.yaml`ファイルを見つけます。
これにより、RancherのUI内で`Bundle`が自動的に入力されます。
［Create］を選択します。
デプロイが成功すると、Bundleは次のようになります：
Figure 33.2: Bundleのデプロイに成功しました #

`Bundle`のデプロイが成功した後、アップグレードの処理を監視するには：

`Upgrade Pod`のログを確認します：
次に、helm-controllerによってアップグレード用に作成されたPodのログを確認します：
1. Pod名は次のテンプレートになります - helm-install-longhorn-<random-suffix>
2. Podは、`HelmChart`リソースがデプロイされたネームスペースに配置されます。今回の場合は`kube-system`です。
  Figure 33.3: 正常にアップグレードされたLonghornチャートのログ #
Rancherの`HelmCharts`セクション（More Resources → HelmCharts）に移動して、`HelmChart`のバージョンが更新されていることを確認します。チャートがデプロイされたネームスペースを選択します。この例では`kube-system`になります。
最後に、Longhorn Podが実行されていることを確認します。

上記の検証を行った後、Longhorn Helmチャートが`1.11.2`バージョンにアップグレードされたと判断して問題ありません。

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

Fleet以外のGitOpsワークフロー（例：Flux）でこのアップグレード手順を使用したいというユースケースがあるかもしれません。

アップグレード手順に必要なリソースを作成するには、generate-chart-upgrade-data.sh スクリプトを使用して、ユーザーが提供したデータで eib-charts-upgrader Fleet を設定できます。この方法の詳細については、Section 33.1.6.2.3.2, “アップグレード手順”を参照してください。

セットアップが完了したら、Kustomize を使用して、クラスターにデプロイ可能な完全に機能するソリューションを生成できます。

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

kustomize build .

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

このワークフローの使用方法を理解するには、Section 33.1.6.2.3.1, “概要” と Section 33.1.6.2.3.2, “アップグレード手順” を参照すると役立ちます。