36 管理クラスタ #
現在、管理クラスタで「Day 2」操作を実行するには、次の2つの方法があります。
36.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など)のアップグレード
36.1.1 前提条件 #
管理クラスタをアップグレードする前に、次の前提条件が満たされている必要があります。
SCC登録ノード- クラスタのノードのOSが、アップグレードするEdgeリリース(53.1項 「要約」)で指定されているOSバージョンをサポートするサブスクリプションキーで登録されていることを確認してください。Upgrade Controller-Upgrade Controllerが管理クラスタにデプロイされていることを確認します。インストール手順については、23.3項 「Upgrade Controllerのインストール」を参照してください。
36.1.2 アップグレード #
管理クラスタをアップグレードするEdgeリリース(53.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 EOFUpgrade ControllerのネームスペースにUpgradePlanをデプロイすると、アップグレードプロセスが開始されます。
注記実際の
アップグレードプロセスの詳細については、23.4項 「Upgrade Controllerの仕組み」を参照してください。アップグレードプロセスを追跡する方法については、23.6項 「アップグレードプロセスの追跡」を参照してください。
36.2 Fleet #
このセクションでは、Fleet (第8章 「Fleet」)コンポーネントを使用して「Day 2」操作を実行する方法について説明します。
次のトピックは、このセクションの一部として説明します。
36.2.1項 「コンポーネント」 - すべての「Day 2」操作に使用されるデフォルトコンポーネント。
36.2.2項 「ユースケースの決定」 - 使用されるFleetカスタムリソースの概要と、これらのリソースがさまざまな「Day 2」操作のユースケースに適しているかどうかを説明します。
36.2.3項 「Day 2ワークフロー」 - Fleetを使用して「Day 2」操作を実行するためのワークフローガイドを提供します。
36.2.4項 「OSアップグレード」 - Fleetを使用してOSアップグレードを実行する方法を説明します。
36.2.5項 「Kubernetesバージョンアップグレード」 - Fleetを使用してKubernetesバージョンのアップグレードを実行する方法を説明します。
36.2.6項 「Helmチャートのアップグレード」 - Fleetを使用してHelmチャートのアップグレードを実行する方法を説明します。
36.2.1 コンポーネント #
以下に、Fleetを使用して「Day
2」操作を正常に実行できるように管理クラスタに設定する必要があるデフォルトコンポーネントの説明を記載しています。
36.2.1.1 Rancher #
オプション:
ダウンストリームクラスタを管理し、System Upgrade
Controllerを管理クラスタ上にデプロイする責任。
詳細については、第5章 「Rancher」を参照してください。
36.2.1.2 System Upgrade Controller (SUC) #
System Upgrade Controllerは、
Planと呼ばれるカスタムリソースを通じて提供される設定データに基づいて指定されたノードでタスクを実行する責任を負います。
SUCは、オペレーティングシステムとKubernetesディストリビューションのアップグレードに積極的に活用されます。
SUCコンポーネントとそれがEdgeスタックにどのように適合するかに関する詳細については、第22章 「System Upgrade Controller」を参照してください。
36.2.2 ユースケースの決定 #
Fleetは2種類のカスタムリソースを使用してKubernetesおよびHelmリソースの管理を有効にします。
以下に、これらのリソースの目的と、「Day 2」操作のコンテキストに最適なユースケースに関する情報を示します。
36.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をエアギャップ環境にデプロイすることもできます。
36.2.2.2 バンドル #
バンドルは、ターゲットクラスタにデプロイする
生のKubernetesリソースを保持します。バンドルは通常、GitRepoリソースから作成されますが、手動でデプロイできるユースケースもあります。詳細については、バンドルのドキュメントを参照してください。
「Day
2」操作のコンテキストでは、バンドルリソースは通常、何らかの形態のローカルGitOps手法を使用しないエアギャップ環境(ローカルGitサーバなど
)でSUCまたはSUC Planをデプロイするために使用されます。
または、ご自身のユースケースでGitOpsワークフローを使用できない場合は(Gitリポジトリを使用する場合など)、バンドルリソースを使用して、SUCまたはSUC
Planを非エアギャップ環境にデプロイすることもできます。
36.2.3 Day 2ワークフロー #
以下に、管理クラスタを特定のEdgeリリースにアップグレードする際に従う必要がある「Day 2」ワークフローを示します。
OSアップグレード(36.2.4項 「OSアップグレード」)
Kubernetesバージョンアップグレード(36.2.5項 「Kubernetesバージョンアップグレード」)
Helmチャートアップグレード(36.2.6項 「Helmチャートのアップグレード」)
36.2.4 OSアップグレード #
このセクションでは、第8章 「Fleet」と第22章 「System Upgrade Controller」を使用してオペレーティングシステムのアップグレードを行う方法について説明します。
次のトピックは、このセクションの一部として説明します。
36.2.4.1項 「コンポーネント」 - アップグレードプロセスで使用される追加のコンポーネント。
36.2.4.2項 「概要」 - アップグレードプロセスの概要。
36.2.4.3項 「要件」 - アップグレードプロセスの要件。
36.2.4.4項 「OSアップグレード - SUC Planのデプロイメント」 -
SUC Planのデプロイ方法に関する情報。このプランはアップグレードプロセスをトリガする責任を負います。
36.2.4.1 コンポーネント #
このセクションでは、 OSアップグレードプロセスがデフォルトの「Day 2」コンポーネント(36.2.1項 「コンポーネント」)よりも使用するカスタムコンポーネントについて説明します。
36.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を使用して以下の処理を実行します。通常のパッケージのアップグレード。このアップグレードにより、すべてのパッケージを最新にすることで、古いパッケージバージョンに関連するマイグレーション時の障害を軽減します。
zypper migrationコマンドを利用したOSマイグレーション。
上記サービスは、OSアップグレードが必要な管理クラスタ上に配置されている必要があるSUC
Planを通じて各ノードに配布されます。
36.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リソースを使用するかバンドルリソースを使用するかは、ユースケースによって異なります。詳細については、36.2.2項 「ユースケースの決定」をご確認ください。
OS SUC Planは、次のワークフローを記述します。
常に、OSをアップグレードする前に、ノードをcordonします。
常に、
ワーカーノードの前にコントロールプレーンノードをアップグレードします。常に、一度に 1ノードずつクラスタをアップグレードします。
OS SUC Planがデプロイされると、ワークフローは次のようになります。
SUCは、デプロイされた
OS SUC Planを照合し、Kubernetes Jobを各ノードに作成します。Kubernetes Jobは、パッケージのアップグレードまたはOSマイグレーションのためにsystemd.service (36.2.4.1.1項 「systemd.service」)を作成します。作成された
systemd.serviceは、特定のノードでOSアップグレードプロセスをトリガします。重要OSアップグレードプロセスが終了すると、対応するノードが
再起動され、システムに更新が適用されます。
上記の説明を以下に図示します。
36.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" ...
エアギャップ:
36.2.4.4 OSアップグレード - SUC Planのデプロイメント #
この手順を使用して以前にアップグレードした環境の場合、ユーザは次の手順のいずれかを完了していることを確認する必要があります。
これは古い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..36.2.4.2項 「概要」で説明したように、OSアップグレードは、次のいずれかの方法を使用してSUC
Planを目的のクラスタに配布することで実行されます。
Fleet
GitRepoリソース - 36.2.4.4.1項 「SUC Planのデプロイメント - GitRepoリソース」。Fleet
バンドルリソース - 36.2.4.4.2項 「SUC Planのデプロイメント - バンドルリソース」。
どのリソースを使用すべきかを判断するには、36.2.2項 「ユースケースの決定」を参照してください。
OS SUC PlanをサードパーティのGitOpsツールからデプロイするユースケースの場合は、36.2.4.4.3項 「SUC Planのデプロイメント - サードパーティのGitOpsワークフロー」を参照してください。
36.2.4.4.1 SUC Planのデプロイメント - GitRepoリソース #
必要なOS SUC Planを配布する、GitRepoリソースは、次の方法のいずれかでデプロイできます。
Rancher UI- 36.2.4.4.1.1項 「GitRepoの作成 - Rancher UI」を通じて(Rancherが利用可能な場合)。リソースを
管理クラスタに手動でデプロイする(36.2.4.4.1.2項 「GitRepoの作成 - 手動」)。
デプロイ後に、ターゲットクラスタのノードのOSアップグレードプロセスを監視するには、22.3項 「System Upgrade Controller Planのモニタリング」を参照してください。
36.2.4.4.1.1 GitRepoの作成 - Rancher UI #
Rancher UIを通じてGitRepoリソースを作成するには、公式のドキュメントに従ってください。
Edgeチームは、すぐに使用できるフリートを維持しています。環境によっては、このフリートを直接使用することも、テンプレートとして使用することもできます。
フリートが配布するSUC
Planにカスタム変更を含める必要がないユースケースでは、ユーザはsuse-edge/fleet-examplesリポジトリから
os-upgradeフリートを直接参照できます。
カスタム変更(カスタム許容値の追加など)が必要な場合、ユーザは別のリポジトリからos-upgradeフリートを参照して、必要に応じてSUC
Planに変更を追加できるようにする必要があります。
GitRepoをsuse-edge/fleet-examplesリポジトリのフリートを使用するように設定する方法の例については、こちらを参照してください。
36.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.4.0/gitrepos/day2/os-upgrade-gitrepo.yamlGitRepo設定を編集します。
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.yamlGitRepoのネームスペースを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.yamlfleet-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.4.0 0/0
36.2.4.4.2 SUC Planのデプロイメント - バンドルリソース #
必要なOS SUC Planを配布するバンドルリソースは、次の方法のいずれかでデプロイできます。
Rancher UI- 36.2.4.4.2.1項 「バンドルの作成 - Rancher UI」を通じて(Rancherが利用可能な場合)。リソースを
管理クラスタに手動でデプロイする(36.2.4.4.2.2項 「バンドルの作成 - 手動」)。
デプロイ後に、ターゲットクラスタのノードのOSアップグレードプロセスを監視するには、22.3項 「System Upgrade Controller Planのモニタリング」を参照してください。
36.2.4.4.2.1 バンドルの作成 - Rancher UI #
Edgeチームは、以下の手順で使用可能な、すぐに使用できるバンドルを維持しています。
RancherのUIを通じてバンドルを作成するには、次の手順に従います。
左上隅で、［☰］ → ［Continuous Delivery (継続的デリバリ)］をクリックします。
［Advanced (詳細)］>［Bundles (バンドル)］ に移動します。
［Create from YAML (YAMLから作成)］を選択します。
ここから次のいずれかの方法でバンドルを作成できます。
注記バンドルが配布する
SUC Planにカスタム変更を含める必要があるユースケースがある場合があります(カスタム許容値の追加など)。これらの変更を、以下の手順で生成されるバンドルに必ず含めてください。バンドルコンテンツを
suse-edge/fleet-examplesから［Create from YAML (YAMLから作成)］ページに手動でコピーする。目的のリリースタグから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 (作成)］を選択します。
36.2.4.4.2.2 バンドルの作成 - 手動 #
バンドルリソースをプルします。
curl -o os-upgrade-bundle.yaml https://raw.githubusercontent.com/suse-edge/fleet-examples/refs/tags/release-3.4.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
36.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 (36.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をデプロイするために使用する方法をよりよく理解するために、概要(36.2.4.2項 「概要」)を確認すると役立つ場合があります。
36.2.5 Kubernetesバージョンアップグレード #
このセクションでは、第8章 「Fleet」と第22章 「System Upgrade Controller」を使用してKubernetesアップグレードを実行する方法について説明します。
次のトピックは、このセクションの一部として説明します。
36.2.5.1項 「コンポーネント」 - アップグレードプロセスで使用される追加のコンポーネント。
36.2.5.2項 「概要」 - アップグレードプロセスの概要。
36.2.5.3項 「要件」 - アップグレードプロセスの要件。
36.2.5.4項 「K8sアップグレード - SUC Planのデプロイメント」 -
SUC Planのデプロイ方法に関する情報。このプランはアップグレードプロセスをトリガする責任を負います。
36.2.5.1 コンポーネント #
このセクションでは、 K8sアップグレードプロセスがデフォルトの「Day 2」コンポーネント(36.2.1項 「コンポーネント」)よりも使用するカスタムコンポーネントについて説明します。
36.2.5.1.1 rke2-upgrade #
特定のノードのRKE2バージョンのアップグレードを担当するコンテナイメージ。
SUC Planに基づいてSUCによって作成されたPodを通じて配布されます。このPlanは、RKE2のアップグレードが必要な各クラスタに配置する必要があります。
rke2-upgradeイメージによるアップグレードの実行方法の詳細については、アップストリームドキュメントを参照してください。
36.2.5.1.2 k3s-upgrade #
特定のノードのK3sバージョンのアップグレードを担当するコンテナイメージ。
SUC Planに基づいてSUCによって作成されたPodを通じて配布されます。このPlanは、K3sのアップグレードが必要な各クラスタに配置する必要があります。
k3s-upgradeイメージによるアップグレードの実行方法の詳細については、アップストリームドキュメントを参照してください。
36.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)を目的のクラスタにデプロイします。
GitRepo/バンドルリソースは常に、管理クラスタ上にデプロイされます。GitRepoリソースを使用するかバンドルリソースを使用するかは、ユースケースによって異なります。詳細については、36.2.2項 「ユースケースの決定」をご確認ください。
K8s SUC Planは、次のワークフローを記述します。
常に、K8sをアップグレードする前に、ノードをcordonします。
常に、
ワーカーノードの前にコントロールプレーンノードをアップグレードします。常に、一度に 1ノードずつ
コントロールプレーンノードをアップグレードし、一度に 2ノードずつワーカーノードをアップグレードします。
K8s SUC Planがデプロイされたら、ワークフローは次のようになります。
SUCは、デプロイ済みの
K8s SUC Planを照合し、Kubernetes Jobを各ノードに作成します。Kubernetesディストリビューションによって、Jobはrke2-upgrade (36.2.5.1.1項 「rke2-upgrade」)またはk3s-upgrade (36.2.5.1.2項 「k3s-upgrade」)のコンテナイメージを実行するPodを作成します。
作成されたPodは次のワークフローを実行します。
ノード上の既存の
rke2/k3sバイナリをrke2-upgrade/k3s-upgradeイメージのバイナリで置き換えます。実行中の
rke2/k3sプロセスを強制終了します。
rke2/k3sプロセスを強制終了すると、再起動がトリガされ、更新されたバイナリを実行する新しいプロセスが起動し、Kubernetesディストリビューションバージョンがアップグレードされます。
上記の説明を以下に図示します。
36.2.5.3 要件 #
Kubernetesディストリビューションをバックアップします。
RKE2クラスタについては、RKE2のバックアップと復元に関するドキュメントを参照してください。
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-upgradeK3s -
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" ...
36.2.5.4 K8sアップグレード - SUC Planのデプロイメント #
この手順を使用して以前にアップグレードした環境の場合、ユーザは次の手順のいずれかを完了していることを確認する必要があります。
これは古い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..36.2.5.2項 「概要」で説明したように、Kubernetesアップグレードは、次のいずれかの方法を使用してSUC
Planを目的のクラスタに配布することで実行されます。
Fleet GitRepoリソース(36.2.5.4.1項 「SUC Planのデプロイメント - GitRepoリソース」)
Fleetバンドルリソース(36.2.5.4.2項 「SUC Planのデプロイメント - バンドルリソース」)
どのリソースを使用すべきかを判断するには、36.2.2項 「ユースケースの決定」を参照してください。
K8s SUC PlanをサードパーティのGitOpsツールからデプロイするユースケースの場合は、36.2.5.4.3項 「SUC Planのデプロイメント - サードパーティのGitOpsワークフロー」を参照してください。
36.2.5.4.1 SUC Planのデプロイメント - GitRepoリソース #
必要なK8s SUC Planを配布する、GitRepoリソースは、次の方法のいずれかでデプロイできます。
Rancher UI- 36.2.5.4.1.1項 「GitRepoの作成 - Rancher UI」を通じて(Rancherが利用可能な場合)。リソースを
管理クラスタに手動でデプロイする(36.2.5.4.1.2項 「GitRepoの作成 - 手動」)。
デプロイ後に、ターゲットクラスタのノードのKubernetesアップグレードプロセスを監視するには、22.3項 「System Upgrade Controller Planのモニタリング」を参照してください。
36.2.5.4.1.1 GitRepoの作成 - Rancher UI #
Rancher UIを通じてGitRepoリソースを作成するには、公式のドキュメントに従ってください。
Edgeチームは、rke2とk3s Kubernetesディストリビューションの両方のすぐに使用できるフリートを維持しています。環境によっては、このフリートを直接使用することも、テンプレートとして使用することもできます。
これらのフリートが配布するSUC
Planにカスタム変更を含める必要がないユースケースの場合、ユーザはsuse-edge/fleet-examplesリポジトリからフリートを直接参照できます。
カスタム変更(カスタム許容値の追加など)が必要な場合、ユーザは別のリポジトリからフリートを参照して、必要に応じてSUC Planに変更を追加できるようにする必要があります。
suse-edge/fleet-examplesリポジトリからフリートを使用したGitRepoリソースの設定例は、次のとおりです。
36.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.4.0/gitrepos/day2/rke2-upgrade-gitrepo.yamlK3sクラスタの場合:
curl -o k3s-upgrade-gitrepo.yaml https://raw.githubusercontent.com/suse-edge/fleet-examples/refs/tags/release-3.4.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.yamlK3sの場合:
# 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.yamlK3sの場合:
# 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.yamlfleet-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
36.2.5.4.2 SUC Planのデプロイメント - バンドルリソース #
必要なKubernetesアップグレードSUC Planを配布する、バンドルリソースは、次の方法のいずれかでデプロイできます。
Rancher UI- 36.2.5.4.2.1項 「バンドルの作成 - Rancher UI」を通じて(Rancherが利用可能な場合)。リソースを
管理クラスタに手動でデプロイする(36.2.5.4.2.2項 「バンドルの作成 - 手動」)。
デプロイ後に、ターゲットクラスタのノードのKubernetesアップグレードプロセスを監視するには、22.3項 「System Upgrade Controller Planのモニタリング」を参照してください。
36.2.5.4.2.1 バンドルの作成 - Rancher UI #
Edgeチームは、rke2とk3s Kubernetesディストリビューションの両方のすぐに使用できるバンドルを維持しています。環境によっては、これらのバンドルを直接使用することも、テンプレートとして使用することもできます。
RancherのUIを通じてバンドルを作成するには、次の手順に従います。
左上隅で、［☰］ → ［Continuous Delivery (継続的デリバリ)］をクリックします。
［Advanced (詳細)］>［Bundles (バンドル)］ に移動します。
［Create from YAML (YAMLから作成)］を選択します。
ここから次のいずれかの方法でバンドルを作成できます。
注記バンドルが配布する
SUC Planにカスタム変更を含める必要があるユースケースがある場合があります(カスタム許容値の追加など)。これらの変更を、以下の手順で生成されるバンドルに必ず含めてください。suse-edge/fleet-examplesから［Create from YAML (YAMLから作成)］ページに RKE2またはK3sのバンドルコンテンツを手動でコピーする。目的のリリースタグから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 (作成)］を選択します。
36.2.5.4.2.2 バンドルの作成 - 手動 #
バンドルリソースをプルします。
RKE2クラスタの場合:
curl -o rke2-plan-bundle.yaml https://raw.githubusercontent.com/suse-edge/fleet-examples/refs/tags/release-3.4.0/bundles/day2/system-upgrade-controller-plans/rke2-upgrade/plan-bundle.yamlK3sクラスタの場合:
curl -o k3s-plan-bundle.yaml https://raw.githubusercontent.com/suse-edge/fleet-examples/refs/tags/release-3.4.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
36.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
これらのPlanリソースは、 System Upgrade
Controllerによって解釈され、アップグレードする各ダウンストリームクラスタにデプロイする必要があります。SUCデプロイメントの情報については、22.2項 「System Upgrade Controllerのインストール」を参照してください。
GitOpsワークフローをKubernetesバージョンアップグレードのSUC
Planをデプロイするために使用する方法をよりよく理解するために、Fleetを使用する更新手順の概要(36.2.5.2項 「概要」)を確認すると役立つ場合があります。
36.2.6 Helmチャートのアップグレード #
このセクションでは、次の内容について説明します。
36.2.6.1項 「エアギャップ環境の準備」 - Edgeに関連するOCIチャートとイメージをプライベートレジストリに配布する方法に関する情報を保持します。
36.2.6.2項 「アップグレード手順」 - 異なるHelmチャートアップグレードのユースケースとそのアップグレード手順に関する情報を保持します。
36.2.6.1 エアギャップ環境の準備 #
36.2.6.1.1 HelmチャートFleetにアクセスできることの確認 #
環境でサポートする内容によって、次のオプションのいずれかを選択できます。
管理クラスタからアクセス可能なローカルGitサーバでチャートのFleetリソースをホストします。FleetのCLIを使用して、直接使用可能でどこかにホストする必要のないバンドルにHelmチャートを変換します。FleetのCLIは、リリースページから取得できます。Macユーザの場合は、fleet-cli Homebrew Formulaeがあります。
36.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リリースに関連するイメージのリストを含みます。
36.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
36.2.6.1.4 Edge OCIチャートイメージアーカイブの作成 #
インターネットにアクセスできるマシンで次の手順を実行します。
edge-save-oci-artefacts.shを実行可能にします。chmod +x edge-save-oci-artefacts.shOCIチャートイメージアーカイブを生成します。
./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
36.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オプションで指定されているレジストリにプッシュします。
36.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チャートイメージをプライベートレジストリにロードします。注記このスクリプトは、
HelmCLIが環境にプリインストールされていることを想定しています。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
36.2.6.1.7 Kubernetesディストリビューションでプライベートレジストリを設定する #
RKE2の場合は、「Private Registry Configuration (プライベートレジストリの設定)」を参照してください。
K3sの場合は、「Private Registry Configuration (プライベートレジストリの設定)」を参照してください。
36.2.6.2 アップグレード手順 #
このセクションでは、Helmアップグレード手順の次のユースケースを中心に説明します。
手動でデプロイしたHelmチャートを確実にアップグレードすることはできません。36.2.6.2.1項 「新しいクラスタがあり、Edge Helmチャートをデプロイして管理したい」で説明する方法を使用してHelmチャートを再デプロイすることをお勧めします。
36.2.6.2.1 新しいクラスタがあり、Edge Helmチャートをデプロイして管理したい #
このセクションでは、以下の実行方法について説明します。
36.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: "107.0.0+up1.9.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チャートのデプロイメントのガイドラインとみなさないでください。
36.2.6.2.1.2 チャートのFleetのデプロイ #
チャートのFleetをデプロイするには、GitRepo (36.2.6.2.1.2.1項 「GitRepo」)またはバンドル(36.2.6.2.1.2.2項 「バンドル」)のいずれかを使用できます。
Fleetをデプロイする場合に、Modifiedメッセージを取得した場合、Fleetのdiffセクションに対応するcomparePatchesエントリを追加してください。詳細については、「Generating Diffs to Ignore
Modified GitRepos (変更されたGitReposを無視する差分を生成する) 」を参照してください。
36.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_url36.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テンプレートから作成し、このバンドルを管理クラスタに手動でデプロイする方法の例を示します。
longhornチャートFleetテンプレートに移動します。
cd fleets/day2/chart-templates/longhorn/longhornFleetにHelmチャートのデプロイ先クラスタを指示する
targets.yamlファイルを作成します。cat > targets.yaml <<EOF targets: # Match your local (management) cluster - clusterName: local EOF注記ローカルクラスタの名前が異なる場合があるユースケースがいくつかあります。
ローカルクラスタ名を取得するには、次のコマンドを実行します。
kubectl get clusters.fleet.cattle.io -n fleet-localfleet-cliを使用して、
LonghornHelmチャートFleetをバンドルリソースに変換します。fleet apply --compress --targets-file=targets.yaml -n fleet-local -o - longhorn-bundle > longhorn-bundle.yamllonghorn-crdチャートFleetテンプレートに移動します。
cd fleets/day2/chart-templates/longhorn/longhorn-crdFleetにHelmチャートのデプロイ先クラスタを指示する
targets.yamlファイルを作成します。cat > targets.yaml <<EOF targets: # Match your local (management) cluster - clusterName: local EOFfleet-cliを使用して、
Longhorn CRDHelmチャートFleetをバンドルリソースに変換します。fleet apply --compress --targets-file=targets.yaml -n fleet-local -o - longhorn-crd-bundle > longhorn-crd-bundle.yamllonghorn-bundle.yamlとlonghorn-crd-bundle.yamlファイルを管理クラスタにデプロイします。kubectl apply -f longhorn-crd-bundle.yaml kubectl apply -f longhorn-bundle.yaml
これらの手順に従うと、SUSE Storageが指定された管理クラスタのすべてにデプロイされます。
36.2.6.2.1.3 デプロイされたHelmチャートの管理 #
Fleetでデプロイした後のHelmチャートのアップグレードについては、36.2.6.2.2項 「Fleetで管理されているHelmチャートをアップグレードしたい場合」を参照してください。
36.2.6.2.2 Fleetで管理されているHelmチャートをアップグレードしたい場合 #
目的のEdgeリリースと互換性を持つように、チャートをアップブレードする必要があるバージョンを決定します。EdgeリリースごとのHelmチャートバージョンはリリースノート(53.1項 「要約」)から表示できます。
Fleetで監視されているGitリポジトリで、Helmチャートの
fleet.yamlファイルを、リリースノート(53.1項 「要約」)から取得した正しいチャートのバージョンとリポジトリで編集します。変更をコミットしてリポジトリにプッシュした後で、目的のHelmチャートのアップグレードがトリガされます。
36.2.6.2.3 EIBを介してデプロイされたHelmチャートをアップグレードしたい #
第11章 「Edge Image Builder」は、HelmChartリソースを作成し、RKE2/K3s
Helm統合機能によって導入されたhelm-controllerを利用して、Helmチャートをデプロイします。
EIBを介してデプロイされたHelmチャートが正常にアップグレードされるようにするには、ユーザは各HelmChartリソースに対してアップグレードを実行する必要があります。
以下に関する情報が提供されています。
アップグレードプロセスの一般的な概要(36.2.6.2.3.1項 「概要」)。
必要なアップグレード手順(36.2.6.2.3.2項 「アップグレード手順」)。
説明した方法を使用したLonghornチャートアップグレードを示す例(36.2.6.2.3.3項 「例」)。
異なるGitOpsツールを使用したアップグレードプロセスを使用する方法(36.2.6.2.3.4項 「サードパーティのGitOpsツールを使用したHelmチャートのアップグレード」)。
36.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フリートに含められます。eib-charts-upgraderFleetを管理クラスタにデプロイします。これはGitRepoリソースまたはバンドルリソースのいずれか通じて実行されます。
デプロイされたら、eib-charts-upgraderがFleetのサポートによって、そのリソースを目的の管理クラスタに配布します。
これらのリソースには、次のものが含まれます。
ユーザが提供するHelmチャートデータを保持する
Secretのセット。前述の
Secretをマウントし、それらに基づいて対応するHelmChartリソースにパッチを適用するPodをデプロイするKubernetes Job。
前述のとおり、これにより、helm-controllerがトリガされ、実際の
Helmチャートアップグレードが実行されます。
上記の説明を以下に図示します。
36.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サーバサポートが可能):
fleets/day2/eib-charts-upgraderFleetを、GitOpsに使用するリポジトリにコピーします。注記Fleetに
generate-chart-upgrade-data.shスクリプトによって加えられた変更が含まれていることを確認してください。eib-charts-upgraderFleetのすべてのリソースを配布するために使用されるGitRepoリソースを設定します。Rancher UIを通じた
GitRepoの設定およびデプロイメントについては、「Accessing Fleet in the Rancher UI (Rancher UIでのFleetへのアクセス)」を参照してください。GitRepo手動設定およびデプロイメントの場合、「Creating a Deployment (デプロイメントの作成)」を参照してください。
GitOpsをサポートしていない環境の場合 (例: エアギャップされ、ローカルGitサーバの使用が許可されていない):
rancher/fleetリリースページからfleet-cliバイナリをダウンロードします(Linuxの場合はfleet-linux-amd64)。Macユーザの場合、使用可能なHomebrew Formulaeがあります(fleet-cli)。eib-charts-upgraderFleetに移動します。cd /foo/bar/fleet-examples/fleets/day2/eib-charts-upgraderリソースをデプロイする場所を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-localfleet-cliを使用して、Fleetをバンドルリソースに変換します。fleet apply --compress --targets-file=targets.yaml -n fleet-local -o - eib-charts-upgrade > bundle.yamlこれにより、
eib-charts-upgraderFleetからのすべてのテンプレート化されたリソースを保持するバンドル(bundle.yaml)が作成されます。fleet applyコマンドに関する詳細については、「fleet apply」を参照してください。Fleetをバンドルに変換する方法に関する詳細については、「 Convert a Helm Chart into a Bundle (Helmチャートのバンドルへの変換)」を参照してください。
バンドルをデプロイします。これは次の2つの方法のいずれかで実行できます。RancherのUIを通じて - ［Continuous Delivery (継続的デリバリ)］→［Advanced (詳細)］→［Bundles (バンドル)］ → ［Create from YAML (YAMLから作成)］に移動して、
bundle.yamlコンテンツを解析するか、［Read from File (ファイルから読み取り)］オプションをクリックして、ファイル自体を渡します。手動 -
管理クラスタ内にbundle.yamlファイルを手動でデプロイします。
これらの手順を実行すると、正常にGitRepo/バンドルリソースがデプロイされます。リソースはFleetによって取得され、そのコンテンツはユーザが以前の手順で指定したターゲットクラスタにデプロイされます。プロセスの概要については、36.2.6.2.3.1項 「概要」を参照してください。
アップグレードプロセスの追跡方法については、36.2.6.2.3.3項 「例」を参照してください。
チャートアップグレードが正常に確認されたら、バンドル/GitRepoリソースを削除します。
これにより、管理クラスタから不要になったアップグレードリソースが削除され、今後バージョンクラッシュが発生しないようになります。
36.2.6.2.3.3 例 #
以下の例は、管理クラスタ上で、EIBを介してデプロイされたHelmチャートを、あるバージョンから別のバージョンにアップグレードする方法を示しています。この例で使用されているバージョンは、推奨バージョンではないことに注意してください。Edgeリリースに固有のバージョン推奨事項については、リリースノート(53.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.4リリースと互換性のあるバージョンにアップグレードする必要があります。つまり、107.0.0+up1.9.1にアップグレードする必要があります。管理クラスタがローカルGitサーバのサポートなしでエアギャップされており、Rancherセットアップが動作していることを前提としています。
アップグレード手順(36.2.6.2.3.2項 「アップグレード手順」)に従います。
release-3.4.0タグからsuse-edge/fleet-exampleリポジトリのクローンを作成します。git clone -b release-3.4.0 https://github.com/suse-edge/fleet-examples.gitLonghornアップグレードアーカイブが保存されるディレクトリを作成します。mkdir archives目的の
Longhornチャートアーカイブバージョンを取得します。# First add the Rancher Helm chart repository helm repo add rancher-charts https://charts.rancher.io/ # Pull the Longhorn 1.9.1 CRD archive helm pull rancher-charts/longhorn-crd --version 107.0.0+up1.9.1 # Pull the Longhorn 1.9.1 chart archive helm pull rancher-charts/longhorn --version 107.0.0+up1.9.1archivesディレクトリ以外で、suse-edge/fleet-examplesリリースタグからgenerate-chart-upgrade-data.shスクリプトをダウンロードします。ディレクトリセットアップは次のようになるはずです。
. ├── archives | ├── longhorn-107.0.0+up1.9.1.tgz │ └── longhorn-crd-107.0.0+up1.9.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.shgenerate-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-107.0.0+up1.9.1.tgz │ └── longhorn-crd-107.0.0+up1.9.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.shGitで変更されたファイルは次のようになるはずです。
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.yamleib-charts-upgraderFleetのバンドルを作成します。まず、Fleet自体に移動します。
cd ./fleet-examples/fleets/day2/eib-charts-upgrader次に、
targets.yamlファイルを作成します。cat > targets.yaml <<EOF targets: - clusterName: local EOF次に、
fleet-cliバイナリを使用して、Fleetをバンドルに変換します。fleet apply --compress --targets-file=targets.yaml -n fleet-local -o - eib-charts-upgrade > bundle.yaml
Rancher UIを通じてバンドルをデプロイします。
図 36.1: Rancher UIを通じたバンドルのデプロイ #ここから、［Read from File (ファイルから読み取り)］を選択し、システムで
bundle.yamlファイルを見つけます。これにより、Rancher UI内に
バンドルが自動入力されます。［Create (作成)］を選択します。
正常にデプロイされたら、バンドルは次のようになります。
図 36.2: 正常にデプロイされたバンドル #
バンドルのデプロイメントが成功した後で、アップグレードプロセスを監視するには次のようにします。
アップグレードPodのログを確認します。
ここで、helm-controllerによってアップグレードに作成されたPodのログを確認します。
Pod名は次のテンプレートを使用します -
helm-install-longhorn-<random-suffix>Podは、
HelmChartリソースがデプロイされたネームスペースにあります。この場合、このネームスペースはkube-systemです。
図 36.3: 正常にアップグレードされたLonghornチャートのログ #
Rancherの
HelmChartsセクション(［More Resources (その他のリソース)］ → ［HelmCharts］)に移動して、HelmChartのバージョンが更新されていることを確認します。チャートがデプロイされたネームスペースを選択します。この例では、kube-systemです。最後に、 Longhorn Podが実行されていることを確認します。
上記の検証後、Longhorn
Helmチャートが107.0.0+up1.9.1バージョンにアップグレードされていると仮定しても問題ないでしょう。
36.2.6.2.3.4 サードパーティのGitOpsツールを使用したHelmチャートのアップグレード #
ユーザがこのアップグレード手順をFleet以外のGitOpsワークフロー(Fluxなど)で実行したいユースケースが存在する場合があります。
アップグレード手順に必要なリソースを生成するには、
generate-chart-upgrade-data.shスクリプトを使用して、ユーザが提供するデータをeib-charts-upgrader
Fleetに入力することができます。この実行方法の詳細については、36.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セットアップに読み込ませることを忘れないでください。
このワークフローの使用方法を理解するには、36.2.6.2.3.1項 「概要」と36.2.6.2.3.2項 「アップグレード手順」を参照すると役立つでしょう。