35 管理クラスタ #

現在、管理クラスタで「Day 2」操作を実行するには、次の2つの方法があります。

第23章「Upgrade Controller」 - 35.1項「Upgrade Controller」を通じて
第8章「Fleet」 - 35.2項「Fleet」を通じて

35.1 Upgrade Controller #

重要

Upgrade Controllerは現在、 非エアギャップ管理クラスタのDay 2操作のみをサポートしています。

このセクションでは、あるEdgeプラットフォームバージョンから別のバージョンに 管理クラスタをアップグレードする方法に関連するさまざまなDay 2操作を実行する方法について説明します。

Day 2操作は、Upgrade Controller (第23章「Upgrade Controller」)によって自動化され、以下のものが含まれます。

SUSE Linux Micro (第9章「SUSE Linux Micro」) OSのアップグレード
第16章「RKE2」または第15章「K3s」 Kubernetesのアップグレード
SUSE追加コンポーネント(SUSE Rancher Prime、SUSE Securityなど)のアップグレード

35.1.1 前提条件 #

管理クラスタをアップグレードする前に、次の前提条件が満たされている必要があります。

SCC登録ノード - クラスタのノードのOSが、アップグレードするEdgeリリース(52.1項「要約」)で指定されているOSバージョンをサポートするサブスクリプションキーで登録されていることを確認してください。
Upgrade Controller - Upgrade Controllerが管理クラスタにデプロイされていることを確認します。インストール手順については、23.3項「Upgrade Controllerのインストール」を参照してください。

35.1.2 アップグレード #

管理クラスタをアップグレードするEdgeリリース(52.1項「要約」)バージョンを決定します。
管理クラスタに、目的のリリースバージョンを指定するUpgradePlanをデプロイします。UpgradePlanはUpgrade Controllerのネームスペースにデプロイされる必要があります。
```
kubectl apply -n <upgrade_controller_namespace> -f - <<EOF
apiVersion: lifecycle.suse.com/v1alpha1
kind: UpgradePlan
metadata:
  name: upgrade-plan-mgmt
spec:
  # Version retrieved from release notes
  releaseVersion: 3.X.Y
EOF
```
注記
UpgradePlanに対して追加の設定を行いたいユースケースがある場合があります。すべての可能な設定については、23.5.1項「UpgradePlan」を参照してください。
Upgrade ControllerのネームスペースにUpgradePlanをデプロイすると、アップグレードプロセスが開始されます。
注記
実際のアップグレードプロセスの詳細については、23.4項「Upgrade Controllerの仕組み」を参照してください。
アップグレードプロセスを追跡する方法については、23.6項「アップグレードプロセスの追跡」を参照してください。

35.2 Fleet #

このセクションでは、Fleet (第8章「Fleet」)コンポーネントを使用して「Day 2」操作を実行する方法について説明します。

次のトピックは、このセクションの一部として説明します。

35.2.1項「コンポーネント」 - すべての「Day 2」操作に使用されるデフォルトコンポーネント。
35.2.2項「ユースケースの決定」 - 使用されるFleetカスタムリソースの概要と、これらのリソースがさまざまな「Day 2」操作のユースケースに適しているかどうかを説明します。
35.2.3項「Day 2ワークフロー」 - Fleetを使用して「Day 2」操作を実行するためのワークフローガイドを提供します。
35.2.4項「OSアップグレード」 - Fleetを使用してOSアップグレードを実行する方法を説明します。
35.2.5項「Kubernetesバージョンアップグレード」 - Fleetを使用してKubernetesバージョンのアップグレードを実行する方法を説明します。
35.2.6項「Helmチャートのアップグレード」 - Fleetを使用してHelmチャートのアップグレードを実行する方法を説明します。

35.2.1 コンポーネント #

以下に、Fleetを使用して「Day 2」操作を正常に実行できるように管理クラスタに設定する必要があるデフォルトコンポーネントの説明を記載しています。

35.2.1.1 Rancher #

オプション: ダウンストリームクラスタを管理し、System Upgrade Controllerを管理クラスタ上にデプロイする責任。

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

35.2.1.2 System Upgrade Controller (SUC) #

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

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

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

35.2.2 ユースケースの決定 #

Fleetは2種類のカスタムリソースを使用してKubernetesおよびHelmリソースの管理を有効にします。

以下に、これらのリソースの目的と、「Day 2」操作のコンテキストに最適なユースケースに関する情報を示します。

35.2.2.1 GitRepo #

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

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

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

35.2.2.2 バンドル #

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

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

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

35.2.3 Day 2ワークフロー #

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

OSアップグレード(35.2.4項「OSアップグレード」)
Kubernetesバージョンアップグレード(35.2.5項「Kubernetesバージョンアップグレード」)
Helmチャートアップグレード(35.2.6項「Helmチャートのアップグレード」)

35.2.4 OSアップグレード #

このセクションでは、第8章「Fleet」と第22章「System Upgrade Controller」を使用してオペレーティングシステムのアップグレードを行う方法について説明します。

次のトピックは、このセクションの一部として説明します。

35.2.4.1項「コンポーネント」 - アップグレードプロセスで使用される追加のコンポーネント。
35.2.4.2項「概要」 - アップグレードプロセスの概要。
35.2.4.3項「要件」 - アップグレードプロセスの要件。
35.2.4.4項「OSアップグレード - SUC Planのデプロイメント」 - SUC Planのデプロイ方法に関する情報。このプランはアップグレードプロセスをトリガする責任を負います。

35.2.4.1 コンポーネント #

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

35.2.4.1.1 systemd.service #

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

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

同じOSバージョン(例: 6.0)を必要とするEdgeバージョンの場合、os-pkg-update.serviceが作成されます。このサービスはtransactional-updateを使用して、通常のパッケージアップグレードを実行します。
OSバージョンのマイグレーション(例: 6.0 → 6.1)が必要なEdgeバージョンの場合、os-migration.serviceが作成されます。このサービスは、transactional-updateを使用して以下の処理を実行します。
1. 通常のパッケージのアップグレード。このアップグレードにより、すべてのパッケージを最新にすることで、古いパッケージバージョンに関連するマイグレーション時の障害を軽減します。
2. zypper migrationコマンドを利用したOSマイグレーション。

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

35.2.4.2 概要 #

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

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

注記

SUC Planは、特定のタスクをノードセットで実行するためにSUCが従う必要がある手順を記述したカスタムリソースです。SUC Planの例については、アップストリームリポジトリを参照してください。

OS SUC Planは、GitRepoまたはバンドルリソースを特定のFleetワークスペースにデプロイすることで、各クラスタに配布されます。FleetはデプロイされたGitRepo/Bundleを取得し、その内容 (OS SUC plan)を目的のクラスタにデプロイします。

注記

GitRepo/バンドルリソースは常に、管理クラスタ上にデプロイされます。GitRepoリソースを使用するかバンドルリソースを使用するかは、ユースケースによって異なります。詳細については、35.2.2項「ユースケースの決定」をご確認ください。

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

常に、OSをアップグレードする前に、ノードをcordonします。
常に、 ワーカーノードの前にコントロールプレーンノードをアップグレードします。
常に、一度に 1ノードずつクラスタをアップグレードします。

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

SUCは、デプロイされたOS SUC Planを照合し、Kubernetes Jobを各ノードに作成します。
Kubernetes Jobは、パッケージのアップグレードまたはOSマイグレーションのためにsystemd.service (35.2.4.1.1項「systemd.service」)を作成します。
作成された systemd.serviceは、特定のノードでOSアップグレードプロセスをトリガします。
重要
OSアップグレードプロセスが終了すると、対応するノードが 再起動され、システムに更新が適用されます。

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

35.2.4.3 要件 #

全般:

SCC登録マシン - すべての管理クラスタノードをhttps://scc.suse.com/に登録する必要があります。これは、各systemd.serviceが目的のRPMリポジトリに正常に接続できるようにするために必要です。
重要
OSバージョンのマイグレーション (例: 6.0 → 6.1)が必要なEdgeリリースの場合、SCCキーが新しいバージョンへのマイグレーションをサポートしていることを確認してください。
SUC PlanのTolerationがノードのTolerationと一致すること - KubernetesクラスタノードにカスタムのTaintが設定されている場合は、SUC PlanにそのTaintに対するTolerationを追加してください。デフォルトでは、SUC Planには、コントロールプレーンノードの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リポジトリにあります。有効なリポジトリリリースタグからの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リポジトリをローカルにミラーリングし、systemd.serviceがそのリポジトリにアクセスできるようにする必要があります。このためには、RMTまたはSUMAのいずれかを使用します。

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

重要

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

管理クラスタから古いEdgeリリースバージョンに関連する以前にデプロイしたSUC Planを削除する - これは、既存のGitRepo/バンドルターゲット設定から目的のクラスタを削除するか、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..

35.2.4.2項「概要」で説明したように、OSアップグレードは、次のいずれかの方法を使用してSUC Planを目的のクラスタに配布することで実行されます。

Fleet GitRepoリソース - 35.2.4.4.1項「SUC Planのデプロイメント - GitRepoリソース」。
Fleetバンドルリソース - 35.2.4.4.2項「SUC Planのデプロイメント - バンドルリソース」。

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

OS SUC PlanをサードパーティのGitOpsツールからデプロイするユースケースの場合は、 35.2.4.4.3項「SUC Planのデプロイメント - サードパーティのGitOpsワークフロー」を参照してください。

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

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

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

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

35.2.4.4.1.1 GitRepoの作成 - Rancher UI #

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

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

重要

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

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

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

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

35.2.4.4.1.2 GitRepoの作成 - 手動 #

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

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

GitRepo設定を編集します。

spec.targetsセクションを削除します。ダウンストリームクラスタにのみ必要です。

# Example using sed
sed -i.bak '/^  targets:/,$d' os-upgrade-gitrepo.yaml && rm -f os-upgrade-gitrepo.yaml.bak

# Example using yq (v4+)
yq eval 'del(.spec.targets)' -i os-upgrade-gitrepo.yaml

GitRepoのネームスペースをfleet-localネームスペースにポイントします。これは、リソースを管理クラスタにデプロイするために実行します。

# Example using sed
sed -i.bak 's/namespace: fleet-default/namespace: fleet-local/' os-upgrade-gitrepo.yaml && rm -f os-upgrade-gitrepo.yaml.bak

# Example using yq (v4+)
yq eval '.metadata.namespace = "fleet-local"' -i os-upgrade-gitrepo.yaml

GitRepoリソースを管理クラスタに適用します。
```
kubectl apply -f os-upgrade-gitrepo.yaml
```

fleet-localネームスペースの下に、作成した GitRepoリソースを表示します。

kubectl get gitrepo os-upgrade -n fleet-local

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

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

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

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

35.2.4.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から作成)］ページが自動入力されます。
Rancher UIでバンドルを編集します。
- バンドルのネームスペースをfleet-localネームスペースを指すように変更します。
```
# Example
kind: Bundle
apiVersion: fleet.cattle.io/v1alpha1
metadata:
  name: os-upgrade
  namespace: fleet-local
...
```
- バンドルのターゲットクラスタをローカル(管理)クラスタを指すように変更します。
```
spec:
  targets:
  - clusterName: local
```
  注記
  一部のユースケースでは、ローカルクラスタに異なる名前を付けることができます。
  ローカルクラスタ名を取得するには、次のコマンドを実行します。
  kubectl get clusters.fleet.cattle.io -n fleet-local
［Create (作成)］を選択します。

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

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

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

バンドル設定を編集します。
- バンドルのターゲットクラスタをローカル(管理)クラスタを指すように変更します。
```
spec:
  targets:
  - clusterName: local
```
  注記
  一部のユースケースでは、ローカルクラスタに異なる名前を付けることができます。
  ローカルクラスタ名を取得するには、次のコマンドを実行します。
  kubectl get clusters.fleet.cattle.io -n fleet-local
- バンドルのネームスペースをfleet-localネームスペースを指すように変更します。
```
# Example
kind: Bundle
apiVersion: fleet.cattle.io/v1alpha1
metadata:
  name: os-upgrade
  namespace: fleet-local
...
```
バンドルリソースを管理クラスタに適用します。
```
kubectl apply -f os-upgrade-bundle.yaml
```
作成したバンドルリソースをfleet-localネームスペースの下に表示します。
```
kubectl get bundles -n fleet-local
```

35.2.4.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は、コントロールプレーンノードのSUC Planリソースです。
plan-worker.yamlは、 ワーカーノードのSUC Planリソースです。
secret.yamlは、systemd.service (35.2.4.1.1項「systemd.service」)の作成を担当する、upgrade.shスクリプトを含むSecretです。
config-map.yamlは、upgrade.shスクリプトによって使用される設定を保持するConfigMapです。

重要

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

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

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

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

次のトピックは、このセクションの一部として説明します。

35.2.5.1項「コンポーネント」 - アップグレードプロセスで使用される追加のコンポーネント。
35.2.5.2項「概要」 - アップグレードプロセスの概要。
35.2.5.3項「要件」 - アップグレードプロセスの要件。
35.2.5.4項「K8sアップグレード - SUC Planのデプロイメント」 - SUC Planのデプロイ方法に関する情報。このプランはアップグレードプロセスをトリガする責任を負います。

35.2.5.1 コンポーネント #

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

35.2.5.1.1 rke2-upgrade #

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

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

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

35.2.5.1.2 k3s-upgrade #

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

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

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

35.2.5.2 概要 #

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

Fleetは、SUC Planを目的のクラスタにデプロイし、管理するために使用されます。

注記

SUC Planは、 SUCが特定のタスクをノードのセットで実行するために従う必要がある手順を記述したカスタムリソースです。SUC Planの例については、アップストリームリポジトリを参照してください。

K8s SUC Planは、 GitRepoまたはバンドルリソースを特定のFleetワークスペースにデプロイすることで各クラスタに配布されます。FleetはデプロイされたGitRepo/バンドルを取得し、その内容(K8s SUC Plan)を目的のクラスタにデプロイします。

注記

K8s SUC Planは、次のワークフローを記述します。

常に、K8sをアップグレードする前に、ノードをcordonします。
常に、 ワーカーノードの前にコントロールプレーンノードをアップグレードします。
常に、一度に 1ノードずつコントロールプレーンノードをアップグレードし、一度に 2ノードずつワーカーノードをアップグレードします。

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

SUCは、デプロイ済みのK8s SUC Planを照合し、 Kubernetes Jobを各ノードに作成します。
Kubernetesディストリビューションによって、Jobはrke2-upgrade (35.2.5.1.1項「rke2-upgrade」)またはk3s-upgrade (35.2.5.1.2項「k3s-upgrade」)のコンテナイメージを実行するPodを作成します。
作成されたPodは次のワークフローを実行します。
1. ノード上の既存のrke2/k3sバイナリをrke2-upgrade/k3s-upgradeイメージのバイナリで置き換えます。
2. 実行中のrke2/k3sプロセスを強制終了します。
rke2/k3sプロセスを強制終了すると、再起動がトリガされ、更新されたバイナリを実行する新しいプロセスが起動し、Kubernetesディストリビューションバージョンがアップグレードされます。

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

35.2.5.3 要件 #

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

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

重要

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

管理クラスタから古いEdgeリリースバージョンに関連する以前にデプロイしたSUC Planを削除する - これは、既存のGitRepo/バンドルターゲット設定から目的のクラスタを削除するか、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..

35.2.5.2項「概要」で説明したように、Kubernetesアップグレードは、次のいずれかの方法を使用してSUC Planを目的のクラスタに配布することで実行されます。

Fleet GitRepoリソース(35.2.5.4.1項「SUC Planのデプロイメント - GitRepoリソース」)
Fleetバンドルリソース(35.2.5.4.2項「SUC Planのデプロイメント - バンドルリソース」)

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

K8s SUC PlanをサードパーティのGitOpsツールからデプロイするユースケースの場合は、 35.2.5.4.3項「SUC Planのデプロイメント - サードパーティのGitOpsワークフロー」を参照してください。

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

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

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

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

35.2.5.4.1.1 GitRepoの作成 - Rancher UI #

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

Edgeチームは、rke2とk3s Kubernetesディストリビューションの両方のすぐに使用できるフリートを維持しています。環境によって、このフリートを直接使用することも、テンプレートとして使用することもできます。

重要

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

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

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

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

35.2.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.3.0/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.3.0/gitrepos/day2/k3s-upgrade-gitrepo.yaml

GitRepo設定を編集します。

spec.targetsセクションを削除します。ダウンストリームクラスタにのみ必要です。

RKE2の場合:

# Example using sed
sed -i.bak '/^  targets:/,$d' rke2-upgrade-gitrepo.yaml && rm -f rke2-upgrade-gitrepo.yaml.bak

# Example using yq (v4+)
yq eval 'del(.spec.targets)' -i rke2-upgrade-gitrepo.yaml

K3sの場合:

# Example using sed
sed -i.bak '/^  targets:/,$d' k3s-upgrade-gitrepo.yaml && rm -f k3s-upgrade-gitrepo.yaml.bak

# Example using yq (v4+)
yq eval 'del(.spec.targets)' -i k3s-upgrade-gitrepo.yaml

GitRepoのネームスペースをfleet-localネームスペースにポイントします。これは、リソースを管理クラスタにデプロイするために実行します。

RKE2の場合:

# Example using sed
sed -i.bak 's/namespace: fleet-default/namespace: fleet-local/' rke2-upgrade-gitrepo.yaml && rm -f rke2-upgrade-gitrepo.yaml.bak

# Example using yq (v4+)
yq eval '.metadata.namespace = "fleet-local"' -i rke2-upgrade-gitrepo.yaml

K3sの場合:

# Example using sed
sed -i.bak 's/namespace: fleet-default/namespace: fleet-local/' k3s-upgrade-gitrepo.yaml && rm -f k3s-upgrade-gitrepo.yaml.bak

# Example using yq (v4+)
yq eval '.metadata.namespace = "fleet-local"' -i k3s-upgrade-gitrepo.yaml

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

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

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

fleet-localネームスペースの下に、作成した GitRepoリソースを表示します。

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

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

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

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

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

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

35.2.5.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から作成)］ページにバンドルコンテンツが自動的に入力されます。
Rancher UIでバンドルを編集します。
- バンドルのネームスペースをfleet-localネームスペースを指すように変更します。
```
# Example
kind: Bundle
apiVersion: fleet.cattle.io/v1alpha1
metadata:
  name: rke2-upgrade
  namespace: fleet-local
...
```
- バンドルのターゲットクラスタをローカル(管理)クラスタを指すように変更します。
```
spec:
  targets:
  - clusterName: local
```
  注記
  一部のユースケースでは、ローカルクラスタに異なる名前を付けることができます。
  ローカルクラスタ名を取得するには、次のコマンドを実行します。
  kubectl get clusters.fleet.cattle.io -n fleet-local
［Create (作成)］を選択します。

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

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

RKE2クラスタの場合:

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

バンドル設定を編集します。
- バンドルのターゲットクラスタをローカル(管理)クラスタを指すように変更します。
```
spec:
  targets:
  - clusterName: local
```
  注記
  一部のユースケースでは、ローカルクラスタに異なる名前を付けることができます。
  ローカルクラスタ名を取得するには、次のコマンドを実行します。
  kubectl get clusters.fleet.cattle.io -n fleet-local
- バンドルのネームスペースをfleet-localネームスペースを指すように変更します。
```
# Example
kind: Bundle
apiVersion: fleet.cattle.io/v1alpha1
metadata:
  name: rke2-upgrade
  namespace: fleet-local
...
```

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

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

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

作成したバンドルリソースをfleet-localネームスペースの下に表示します。

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

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

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

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

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

必要なK8sアップグレードリソースを取得するには、まず使用する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を使用して更新手順の概要(35.2.5.2項「概要」)を確認すると役立つ場合があります。

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

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

35.2.6.1項「エアギャップ環境の準備」 - Edgeに関連するOCIチャートとイメージをプライベートレジストリに配布する方法に関する情報を保持します。
35.2.6.2項「アップグレード手順」 - 異なるHelmチャートアップグレードのユースケースとそのアップグレード手順に関する情報を保持します。

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

35.2.6.1.1 HelmチャートFleetにアクセスできることの確認 #

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

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

35.2.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リリースに関連するイメージのリストを含みます。

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

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

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

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

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

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

K3sの場合は、「Private Registry Configuration (プライベートレジストリの設定)」を参照してください。

35.2.6.2 アップグレード手順 #

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

重要

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

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

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

35.2.6.2.1.1 チャートのFleetリソースの準備 #

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

注記

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

failed pre-install: context deadline exceeded

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

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

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

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

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

defaultNamespace: longhorn-system

helm:
  # timeoutSeconds: 10
  releaseName: "longhorn"
  chart: "longhorn"
  repo: "https://charts.rancher.io/"
  version: "106.2.0+up1.8.1"
  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チャートのデプロイメントのガイドラインとみなさないでください。

35.2.6.2.1.2 チャートのFleetのデプロイ #

チャートのFleetをデプロイするには、GitRepo (35.2.6.2.1.2.1項「GitRepo」)またはバンドル(35.2.6.2.1.2.2項「バンドル」)のいずれかを使用できます。

注記

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

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

35.2.6.2.1.2.2 バンドル #

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

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

Edge Helmチャートのバンドルは、Fleetの「Convert a Helm Chart into a Bundle (Helmチャートをバンドルに変換する」アプローチを利用して作成できます。

以下に、バンドルリソースをlonghorn と longhorn-crd HelmチャートFleetテンプレートから作成し、このバンドルを管理クラスタに手動でデプロイする方法の例を示します。

注記

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

longhornチャートFleetテンプレートに移動します。
```
cd fleets/day2/chart-templates/longhorn/longhorn
```
FleetにHelmチャートのデプロイ先クラスタを指示するtargets.yamlファイルを作成します。
```
cat > targets.yaml <<EOF
targets:
# Match your local (management) cluster
- clusterName: local
EOF
```
注記
ローカルクラスタの名前が異なる場合があるユースケースがいくつかあります。
ローカルクラスタ名を取得するには、次のコマンドを実行します。
```
kubectl get clusters.fleet.cattle.io -n fleet-local
```
fleet-cliを使用して、Longhorn HelmチャートFleetをバンドルリソースに変換します。
注記
FleetのCLI は、リリースアセットページから取得できます(fleet-linux-amd64)。
Macユーザの場合、fleet-cli Homebrew Formulaeがあります。
```
fleet apply --compress --targets-file=targets.yaml -n fleet-local -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:
# Match your local (management) cluster
- clusterName: local
EOF
```

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

fleet apply --compress --targets-file=targets.yaml -n fleet-local -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
```

これらの手順に従うと、SUSE Storageが指定された管理クラスタのすべてにデプロイされます。

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

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

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

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

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

第11章「Edge Image Builder」は、HelmChartリソースを作成し、RKE2/K3s Helm統合機能によって導入されたhelm-controllerを利用して、Helmチャートをデプロイします。

EIBを介してデプロイされたHelmチャートが正常にアップグレードされるようにするには、ユーザは各HelmChartリソースに対してアップグレードを実行する必要があります。

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

アップグレードプロセスの一般的な概要(35.2.6.2.3.1項「概要」)。
必要なアップグレード手順(35.2.6.2.3.2項「アップグレード手順」)。
説明した方法を使用したLonghornチャートアップグレードを示す例(35.2.6.2.3.3項「例」)。
異なるGitOpsツールを使用したアップグレードプロセスを使用する方法(35.2.6.2.3.4項「サードパーティのGitOpsツールを使用したHelmチャートのアップグレード」)。

35.2.6.2.3.1 概要 #

EIBを介してデプロイされたHelmチャートは、eib-charts-upgraderと呼ばれるフリートを通じてアップグレードされます。

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

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

ユーザは以下を行うことのみ求められます。

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

デプロイされたら、eib-charts-upgraderがFleetのサポートによって、そのリソースを目的の管理クラスタに配布します。

これらのリソースには、次のものが含まれます。

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

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

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

35.2.6.2.3.2 アップグレード手順 #

正しいリリースタグから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スクリプトを実行します。
```
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によって指定されたフリートのbase/secretsディレクトリに保存されます。
generate-chart-upgrade-data.shスクリプトは、フリートに追加の変更も適用し、生成されたKubernetes Secret YAMLファイルが、フリートによってデプロイされたワークロードによって正しく利用されるようにします。
重要
ユーザは、generate-chart-upgrade-data.shスクリプトが生成する内容に変更を加えてはなりません。

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

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バイナリをダウンロードします(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 map the local(management) cluster
- clusterName: local
EOF
```
  注記
  一部のユースケースでは、ローカルクラスタに異なる名前を付けることができます。
  ローカルクラスタ名を取得するには、次のコマンドを実行します。
  kubectl get clusters.fleet.cattle.io -n fleet-local
4. fleet-cliを使用して、Fleetを バンドルリソースに変換します。
```
fleet apply --compress --targets-file=targets.yaml -n fleet-local -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によって取得され、そのコンテンツはユーザが以前の手順で指定したターゲットクラスタにデプロイされます。プロセスの概要については、35.2.6.2.3.1項「概要」を参照してください。

アップグレードプロセスの追跡方法については、35.2.6.2.3.3項「例」を参照してください。

重要

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

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

35.2.6.2.3.3 例 #

注記

以下の例は、管理クラスタ上で、EIBを介してデプロイされたHelmチャートを、あるバージョンから別のバージョンにアップグレードする方法を示しています。この例で使用されているバージョンは、推奨バージョンではないことに注意してください。Edgeリリースに固有のバージョン推奨事項については、リリースノート(52.1項「要約」)を参照してください。

ユースケース:

管理クラスタで、古いバージョンのLonghornが実行されています。

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

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.3.1リリースと互換性のあるバージョンにアップグレードする必要があります。つまり、106.2.0+up1.8.1にアップグレードする必要があります。
管理クラスタがローカルGitサーバのサポートなしでエアギャップされており、Rancherセットアップが動作していることを前提としています。

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

release-3.3.0タグからsuse-edge/fleet-exampleリポジトリのクローンを作成します。
```
git clone -b release-3.3.0 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.8.1 CRD archive
helm pull rancher-charts/longhorn-crd --version 106.2.0+up1.8.1

# Pull the Longhorn 1.8.1 chart archive
helm pull rancher-charts/longhorn --version 106.2.0+up1.8.1

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

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

.
├── archives
|   ├── longhorn-106.2.0+up1.8.1.tgz
│   └── longhorn-crd-106.2.0+up1.8.1.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-106.2.0+up1.8.1.tgz
│   └── longhorn-crd-106.2.0+up1.8.1.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

eib-charts-upgrader Fleetのバンドルを作成します。
1. まず、Fleet自体に移動します。
```
cd ./fleet-examples/fleets/day2/eib-charts-upgrader
```
2. 次に、targets.yamlファイルを作成します。
```
cat > targets.yaml <<EOF
targets:
- clusterName: local
EOF
```
3. 次に、fleet-cliバイナリを使用して、Fleetをバンドルに変換します。
```
fleet apply --compress --targets-file=targets.yaml -n fleet-local -o - eib-charts-upgrade > bundle.yaml
```
Rancher UIを通じてバンドルをデプロイします。
図 35.1: Rancher UIを通じたバンドルのデプロイ #

ここから、［Read from File (ファイルから読み取り)］を選択し、システムでbundle.yamlファイルを見つけます。
これにより、Rancher UI内にバンドルが自動入力されます。
［Create (作成)］を選択します。
正常にデプロイされたら、バンドルは次のようになります。
図 35.2: 正常にデプロイされたバンドル #

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

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

上記の検証後、Longhorn Helmチャートが106.2.0+up1.8.1バージョンにアップグレードされていると仮定しても問題ないでしょう。

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

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

アップグレード手順に必要なリソースを生成するには、 generate-chart-upgrade-data.shスクリプトを使用して、ユーザが提供するデータをeib-charts-upgrader Fleetに入力することができます。この実行方法の詳細については、35.2.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セットアップに読み込ませることを忘れないでください。

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