32 管理クラスタ #
現在、management クラスターで「Day 2」操作を実行する方法は2つあります。
32.1 Upgrade Controller #
`Upgrade Controller`は現在、*非エアギャップ管理*クラスターに対する`Day 2`操作のみをサポートしています。
このセクションでは、Day 2`クラスターをある`management`プラットフォームバージョンから別のバージョンへアップグレードする際に関連する、さまざまなSUSE Edge`操作の実行方法について説明します。
`Day 2`操作はUpgrade Controller (Chapter 19, Upgrade Controller)によって自動化されており、以下が含まれます。
SUSE Linux Micro (Chapter 7, SUSE Linux Micro) OSアップグレード
Chapter 12, RKE2またはChapter 11, K3s Kubernetesアップグレード
SUSE追加コンポーネント（SUSE Rancher Prime、SUSE Securityなど）のアップグレード
32.1.1 前提条件 #
`management`クラスターをアップグレードする前に、以下の前提条件を満たす必要があります。
SCC registered nodes- クラスターノードのOSが、アップグレード先の`SUSE Edge`リリース (Chapter 41, リリースノート)で指定されているOSバージョンをサポートするサブスクリプションキーで登録されていることを確認してください。Upgrade Controller- `Upgrade Controller`が`management`クラスターにデプロイされていることを確認してください。インストール手順については、Section 19.3, “Upgrade Controllerのインストール”を参照してください。
32.1.2 アップグレード #
SUSE Edge`クラスターのアップグレード先となるリリース (Chapter 41, リリースノート)バージョンを決定します。`management`management`クラスターに、目的の`UpgradePlan`を指定する`release version`をデプロイします。`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
Note`UpgradePlan`に対して追加の設定を行いたいユースケースがあるかもしれません。可能なすべての設定については、Section 19.6.1, “UpgradePlan”を参照してください。
`UpgradePlan`を`Upgrade Controller’s`ネームスペースにデプロイすると、`upgrade process`が開始されます。
Note実際の`upgrade process`の詳細については、Section 19.5, “Upgrade Controllerはどのように機能しますか？”を参照してください。
`upgrade process`の追跡方法については、Section 19.7, “アップグレードプロセスの追跡”を参照してください。
32.1.3 アップグレード後の手順 #
最新の`SUSE Edge` z-streamから`3.5`への`3.6.0`のアップグレードでは、Upgrade Controller`がアップグレードプロセスを完了した後に、最終的な手動手順を実行する必要がある場合があります。これらは、SUSE Edge`リリース以降、`3.6`で唯一サポートされるイングレスコントローラーとしてIngress-NGINXをTraefikに置き換えることに関連しています。
RKE2/K3sに統合された`Traefik`イングレスプロバイダーは、SUSE Edge 3.6`リリースでサポートされる唯一のイングレスコントローラーです。複雑なイングレス移行シナリオをサポートするために`Ingress-NGINX`と`Traefik`を一時的に並行して実行することは可能ですが、それはSUSE Edge`管理クラスターやダウンストリームクラスターがバージョン`3.6`にアップグレードされた後、かつ移行に必要な期間に限られます。
RKE2 Ingress NGINXからTraefikへの移行 ガイドでは、`Traefik`イングレスコントローラーが廃止された`Ingress-NGINX`に置き換わった後に利用可能なイングレス移行パスの詳細を提供しています。
もし、アップグレード開始前の管理クラスターでデフォルトのIngress-NGINXを使用しており、`Traefik`イングレスコントローラーを利用していなかった場合は、アップグレード後に`Traefik`を手動でデプロイする必要があります。
まず、デプロイ済みのIngress-NGINXインスタンスが適切に設定されていることを確認します（例：２つのイングレスコントローラー間でPodの不要なhostPort競合を回避するために）：
kubectl apply -f - <<- EOF
apiVersion: helm.cattle.io/v1
kind: HelmChartConfig
metadata:
name: rke2-ingress-nginx
namespace: kube-system
spec:
valuesContent: |-
controller:
hostPort:
enabled: false # not needed when exposing through a type:LoadBalancer service
config:
use-forwarded-headers: "true"
enable-real-ip: "true"
publishService:
enabled: true
service:
enabled: true
type: LoadBalancer
externalTrafficPolicy: Local
EOF次に、`Traefik`と`rke2-traefik-crd`の両方のHelmチャートをインストールすることで、`rke2-traefik`のデプロイを進めることができます。
以下に示すように`HelmChart`マニフェストを使ってこれらのHelmチャートをデプロイすることで、`Upgrade Controller`が将来の管理クラスターアップグレード時にもこれらのHelmチャートのアップグレードを担うことを保証します。
kubectl apply -f - <<- EOF
apiVersion: helm.cattle.io/v1
kind: HelmChart
metadata:
name: rke2-traefik-crd
namespace: kube-system
spec:
chart: rke2-traefik-crd
version: {rke2-traefik-crd Helm chart version}
repo: https://rke2-charts.rancher.io
bootstrap: false
failurePolicy: reinstall
backOffLimit: 20
targetNamespace: kube-system
set:
global.cattle.systemDefaultRegistry: registry.rancher.com
global.rke2DataDir: /var/lib/rancher/rke2
global.systemDefaultRegistry: registry.rancher.com
---
apiVersion: helm.cattle.io/v1
kind: HelmChart
metadata:
name: rke2-traefik
namespace: kube-system
spec:
chart: rke2-traefik
version: {rke2-traefik Helm chart version}
repo: https://rke2-charts.rancher.io
bootstrap: false
failurePolicy: reinstall
backOffLimit: 20
targetNamespace: kube-system
set:
global.cattle.systemDefaultRegistry: registry.rancher.com
global.rke2DataDir: /var/lib/rancher/rke2
global.systemDefaultRegistry: registry.rancher.com
valuesContent: |-
ingressClass:
isDefaultClass: false # if traefik deployed alongside ingress-nginx
ports:
web:
hostPort: null # disallow hostPort
exposedPort: 80
websecure:
hostPort: null # disallow hostPort
exposedPort: 443
service:
enabled: true
type: LoadBalancer
spec:
externalTrafficPolicy: Local
allocateLoadBalancerNodePorts: false # k8s GA from 1.24; supported by MetalLB
providers:
kubernetesIngressNginx: # this provider allows traefik to "understand" most of the ingress-nginx annotations
enabled: true
ingressClass: "rke2-ingress-nginx-migration"
controllerClass: "rke2.cattle.io/ingress-nginx-migration"
EOF{rke2-traefik-crd Helm chart version}`と{rke2-traefik-crd Helm chart version}`は、アップグレードしたRKE2/K3sのバージョンにより定められたものです。
最後のステップでは、LoadBalancerタイプのサービスを通じて`Traefik`サービスを公開するために、MetalLBが必要とするオブジェクトを作成します：
kubectl apply -f - <<- EOF
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
name: ingress-ippool-traefik
namespace: metallb-system
spec:
addresses:
- {EXTERNAL_IP_FOR_TRAEFIK_SERVICE}/32
serviceAllocation:
priority: 100
serviceSelectors:
- matchExpressions:
- {key: app.kubernetes.io/name, operator: In, values: [rke2-traefik]}
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
name: ingress-l2-adv-traefik
namespace: metallb-system
spec:
ipAddressPools:
- ingress-ippool-traefik
EOFこれで、`Traefik`と`Ingress-NGINX`が並行して稼働し、一方からもう一方へ安全に必要なイングレスの移行を実施できるようになります。
すべてのイングレスが移行され、`Ingress-NGINX`が不要になったら、不必要なリソース消費を防ぐために、必ずこれをアンインストールし、関連する全てのリソースをクリーンアップしてください。
32.2 Fleet #
本セクションでは、Fleet (Chapter 6, Fleet)コンポーネントを使用して「Day 2」オペレーションを実行する方法について説明します。
本セクションでは、以下のトピックを扱います。
Section 32.2.1, “コンポーネント” - すべての「Day 2」オペレーションで使用されるデフォルトコンポーネント。
Section 32.2.2, “ユースケースの特定” - 使用されるFleetカスタムリソースの概要と、さまざまな「Day 2」オペレーションのユースケースへの適合性について説明します。
Section 32.2.3, “Day 2 ワークフロー” - Fleetを使用して「Day 2」オペレーションを実行するためのワークフローガイドを提供します。
Section 32.2.4, “OSのアップグレード” - Fleetを使用してOSアップグレードを実行する方法について説明します。
Section 32.2.5, “Kubernetesバージョンのアップグレード” - Fleetを使用してKubernetesバージョンのアップグレードを実行する方法について説明します。
Section 32.2.6, “Helmチャートのアップグレード” - Fleetを使用してHelmチャートのアップグレードを実行する方法について説明します。
32.2.1 コンポーネント #
以下に、Fleetを使用して「Day 2」オペレーションを正常に実行するために、`management`クラスター上にセットアップする必要があるデフォルトコンポーネントの説明を記載します。
32.2.1.1 Rancher #
オプション。`downstream clusters`の管理および`System Upgrade Controller`への`management cluster`のデプロイを担当します。
詳細については、Chapter 4, Rancherを参照してください。
32.2.1.2 System Upgrade Controller (SUC) #
*System Upgrade Controller*は、`Plan`と呼ばれるカスタムリソースを通じて提供される設定データに基づき、指定されたノードでタスクを実行する役割を担います。
*SUC*は、オペレーティングシステムおよびKubernetesディストリビューションのアップグレードに積極的に活用されています。
*SUC*コンポーネントの詳細およびEdgeスタックにおける位置付けについては、Chapter 18, System Upgrade Controllerを参照してください。
32.2.2 ユースケースの特定 #
Fleetは、KubernetesおよびHelmリソースの管理を可能にするために、2種類のカスタムリソースを使用します。
以下に、これらのリソースの目的と、「Day 2」オペレーションの文脈において最適なユースケースに関する情報を記載します。
32.2.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 リソースを使用することもできます。
32.2.2.2 バンドル #
Bundles は、ターゲットクラスターにデプロイされる raw Kubernetes リソースを保持します。通常、これらは GitRepo リソースから作成されますが、手動でデプロイできるユースケースもあります。詳細については、 Bundleマニュアルを参照してください。
「Day 2」運用のコンテキストでは、Bundle リソースは通常、ローカル GitOps 手順（例：ローカル git サーバー）を使用しない エアギャップ(された) 環境で SUC または SUC Plans をデプロイするために使用されます。
あるいは、ユースケースで GitOps ワークフロー（Git リポジトリの使用など）が許可されない場合は、非エアギャップ(された) 環境で SUC または SUC Plans をデプロイするために Bundle リソースを使用することもできます。
32.2.3 Day 2 ワークフロー #
以下は、management クラスターを特定の Edge リリースにアップグレードする際に従うべき「Day 2」ワークフローです。
OS upgrade (Section 32.2.4, “OSのアップグレード”)
Kubernetes version upgrade (Section 32.2.5, “Kubernetesバージョンのアップグレード”)
Helm チャートアップグレード (Section 32.2.6, “Helmチャートのアップグレード”)
32.2.4 OSのアップグレード #
このセクションでは、Chapter 6, FleetとChapter 18, System Upgrade Controllerを使用してオペレーティングシステムのアップグレードを実行する方法について説明します。
このセクションでは、以下のトピックについて説明します。
Section 32.2.4.1, “コンポーネント” - アップグレードプロセスで使用される追加コンポーネント。
Section 32.2.4.2, “概要” - アップグレードプロセスの概要。
Section 32.2.4.3, “要件” - アップグレードプロセスの要件。
Section 32.2.4.4, “OS アップグレード - SUC プランのデプロイメント” - アップグレードプロセスをトリガーする役割を担う`SUC plans`のデプロイ方法についての情報。
32.2.4.1 コンポーネント #
このセクションでは、`OS upgrade`プロセスがデフォルトの「Day 2」コンポーネント (Section 32.2.1, “コンポーネント”)の代わりに使用するカスタムコンポーネントについて説明します。
32.2.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`が作成されます。これはトランザクション更新を使用して、以下を実行します。すべてのパッケージが最新であることを保証し、古いパッケージバージョンに関連する移行のエラーを軽減するための通常のパッケージアップグレード。
`zypper migration`コマンドを利用したOS移行。
上記のサービスは、OSアップグレードが必要なmanagementクラスター上に配置する必要がある`SUC plan`を通じて、各ノードに配布されます。
32.2.4.2 概要 #
managementクラスターノードのオペレーティングシステムのアップグレードは、`Fleet`と`System Upgrade Controller (SUC)`を利用して行われます。
*Fleet*は、目的のクラスターに`SUC plans`をデプロイおよび管理するために使用されます。
`SUC plans`は、特定のタスクを一連のノード上で実行するために`SUC`が従うべき手順を記述するカスタムリソースです。`SUC plan`がどのようなものかの例については、アップストリームリポジトリを参照してください。
OS SUC plans`は、特定のFleet ワークスペースに GitRepoまたは Bundleリソースをデプロイすることで、各クラスターに配布されます。Fleetはデプロイされた`GitRepo/Bundle`を取得し、その内容（`OS SUC plans）を目的のクラスターにデプロイします。
`GitRepo/Bundle`リソースは常に`management cluster`にデプロイされます。`GitRepo`リソースと`Bundle`リソースのどちらを使用するかはユースケースによって異なります。詳細についてはSection 32.2.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 32.2.4.1.1, “systemd.service”)を作成します。
作成された`systemd.service`は、特定のノードでOSアップグレードプロセスをトリガーします。
ImportantOSアップグレードプロセスが完了すると、システムに更新を適用するために、対応するノードが`rebooted`されます。
上記の説明の図を以下に示します。
32.2.4.3 要件 #
全般:
SCC登録済みマシン - すべてのmanagementクラスターノードは、それぞれの`https://scc.suse.com/`が目的のRPMリポジトリに正常に接続できるようにするために必要な`systemd.service`に登録されている必要があります。
ImportantOSバージョンの移行（例:
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" ...
エアギャップ(された):
32.2.4.4 OS アップグレード - SUC プランのデプロイメント #
この手順を使用して以前にアップグレードされた環境の場合、ユーザーは以下のいずれかの手順が完了していることを確認する必要があります：
Remove any previously deployed SUC Plans related to older Edge release versions from the management cluster- 既存のGitRepo/Bundleターゲット設定 から目的のクラスターを削除するか、GitRepo/Bundleリソースを完全に削除することで実行できます。Reuse the existing GitRepo/Bundle resource- リソースのリビジョンを、目的のsuse-edge/fleet-examplesリリース に適したフリートを保持する新しいタグに向けることで実行できます。
これは、古い Edge リリースバージョンの SUC Plans との競合を避けるために行われます。
ユーザーがアップグレードを試みる際に management クラスター上に既存の 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 32.2.4.2, “概要” で述べたように、OS のアップグレードは、以下のいずれかの方法で目的のクラスターに SUC plans を送信することによって行われます：
Fleet
GitRepoリソース - Section 32.2.4.4.1, “SUC プランのデプロイメント - GitRepo リソース”。Fleet
Bundleリソース - Section 32.2.4.4.2, “SUCプランのデプロイメント - Bundleリソース”。
どのリソースを使用すべきかを判断するには、Section 32.2.2, “ユースケースの特定” を参照してください。
サードパーティの GitOps ツールから OS SUC plans をデプロイしたいユースケースについては、Section 32.2.4.4.3, “SUCプランのデプロイ - サードパーティのGitOpsワークフロー” を参照してください。
32.2.4.4.1 SUC プランのデプロイメント - GitRepo リソース #
必要な OS SUC plans を送信する GitRepo リソースは、以下のいずれかの方法でデプロイできます：
Rancher UI- Section 32.2.4.4.1.1, “GitRepoの作成 - Rancher UI” を通じて（`Rancher`が利用可能な場合）。リソースを手動でデプロイ (Section 32.2.4.4.1.2, “GitRepoの作成 - 手動”) して、
management clusterに適用します。
デプロイ後、ターゲットクラスターのノードのOSアップグレードプロセスを監視するには、Section 18.3, “System Upgrade Controllerプランの監視” を参照してください。
32.2.4.4.1.1 GitRepoの作成 - Rancher UI #
Rancher UIを通じて GitRepo リソースを作成するには、公式の ドキュメント に従ってください。
Edgeチームは、すぐに使用できる Fleet を維持管理しています。環境によっては、このFleetを直接使用することも、テンプレートとして使用することもできます。
Fleetが提供する SUC plans にカスタム変更を含める必要がないユースケースでは、ユーザーは suse-edge/fleet-examples リポジトリから os-upgrade Fleetを直接参照できます。
カスタム変更が必要な場合（カスタムテイントの追加など）、ユーザーは別のリポジトリから os-upgrade Fleetを参照し、必要に応じてSUCプランに変更を追加できるようにする必要があります。
GitRepo が suse-edge/fleet-examples リポジトリのFleetを使用するように構成する方法の例は、こちらで確認できます。
32.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.6.1/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
`management cluster`に*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.6.1 0/0
32.2.4.4.2 SUCプランのデプロイメント - Bundleリソース #
必要なを配布する*Bundle*`OS SUC Plans`リソースは、以下のいずれかの方法でデプロイできます。
Rancher UI- Section 32.2.4.4.2.1, “Bundleの作成 - Rancher UI” を通じて（`Rancher`が利用可能な場合）。リソースを手動でデプロイ (Section 32.2.4.4.2.2, “バンドルの作成 - 手動”) して、
management clusterに適用します。
デプロイ後、ターゲットクラスターのノードのOSアップグレードプロセスを監視するには、Section 18.3, “System Upgrade Controllerプランの監視” を参照してください。
32.2.4.4.2.1 Bundleの作成 - Rancher UI #
Edgeチームは、以下の手順で使用できるすぐに使えるbundleを管理しています。
RancherのUIからBundleを作成するには：
左上隅で、*☰ → Continuous Delivery*をクリックします。
Advanced > *Bundles*に移動します。
*Create from YAML*を選択します。
ここから、以下のいずれかの方法でBundleを作成できます。
NoteBundleが配布する`SUC plans`にカスタム変更を含める必要があるユースケースがあるかもしれません（例：カスタムのtolerationを追加する場合など）。以下の手順で生成されるBundleに、それらの変更を必ず含めてください。
`suse-edge/fleet-examples`からbundle contentを手動でコピーし、*Create from YAML*ページに貼り付けます。
目的の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の内容が自動的に入力されます。
Rancher UIでバンドルを編集します。
Bundle`の*ネームスペース*を変更して、fleet-local`ネームスペースを指すようにします。# Example kind: Bundle apiVersion: fleet.cattle.io/v1alpha1 metadata: name: os-upgrade namespace: fleet-local ...Bundle`の*ターゲット*クラスターを変更して、`local（管理）クラスターを指すようにします。spec: targets: - clusterName: localNote`local`クラスターの名前が異なる場合があるユースケースがいくつかあります。
`local`クラスター名を取得するには、以下のコマンドを実行します。
kubectl get clusters.fleet.cattle.io -n fleet-local
［作成］を選択します。
32.2.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`設定を編集します。
Bundle`の*ターゲット*クラスターを変更して、`local（管理）クラスターを指すようにします。spec: targets: - clusterName: localNote`local`クラスターの名前が異なる場合があるユースケースがいくつかあります。
`local`クラスター名を取得するには、以下のコマンドを実行します。
kubectl get clusters.fleet.cattle.io -n fleet-localBundle`の*ネームスペース*を変更して、fleet-local`ネームスペースを指すようにします。# Example kind: Bundle apiVersion: fleet.cattle.io/v1alpha1 metadata: name: os-upgrade namespace: fleet-local ...
*バンドル*リソースを`management cluster`に適用します。
kubectl apply -f os-upgrade-bundle.yaml作成された*バンドル*リソースを`fleet-local`ネームスペースの下で表示します。
kubectl get bundles -n fleet-local
32.2.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 32.2.4.1.1, “systemd.service”)を作成する役割を担う`upgrade.sh`スクリプトを含むシークレットです。
`config-map.yaml`は、`upgrade.sh`スクリプトによって使用される設定を保持するConfigMapです。
これらの`Plan`リソースは`System Upgrade Controller`によって解釈されるため、アップグレードする各ダウンストリームクラスターに展開する必要があります。SUCの展開に関する情報については、Section 18.2, “System Upgrade Controllerのインストール”を参照してください。
OSアップグレード用の*SUC Plans*を展開するためにGitOpsワークフローをどのように使用できるかをより深く理解するには、overview (Section 32.2.4.2, “概要”)を参照すると役立ちます。
32.2.5 Kubernetesバージョンのアップグレード #
このセクションでは、Chapter 6, FleetとChapter 18, System Upgrade Controllerを使用してKubernetesのアップグレードを実行する方法について説明します。
このセクションでは、以下のトピックについて説明します。
Section 32.2.5.1, “コンポーネント” - アップグレードプロセスで使用される追加コンポーネント。
Section 32.2.5.2, “概要” - アップグレードプロセスの概要。
Section 32.2.5.3, “要件” - アップグレードプロセスの要件。
Section 32.2.5.4, “K8sアップグレード - SUCプランのデプロイメント” - アップグレードプロセスをトリガーする役割を担う`SUC plans`のデプロイ方法に関する情報。
32.2.5.1 コンポーネント #
このセクションでは、デフォルトの「Day 2」コンポーネント (Section 32.2.1, “コンポーネント”)に加えて`K8s upgrade`プロセスが使用するカスタムコンポーネントについて説明します。
32.2.5.1.1 rke2-upgrade #
特定のノードのRKE2バージョンをアップグレードするためのコンテナイメージ。
*SUCプラン*に基づいて*SUC*によって作成されたPodを通じて提供されます。このプランは、RKE2のアップグレードが必要な各*クラスター*に配置する必要があります。
`rke2-upgrade`イメージがどのようにアップグレードを実行するかについての詳細は、アップストリームドキュメントを参照してください。
32.2.5.1.2 k3s-upgrade #
特定のノードのK3sバージョンをアップグレードするためのコンテナイメージ。
*SUCプラン*に基づいて*SUC*によって作成されたPodを通じて提供されます。このプランは、K3sのアップグレードが必要な各*クラスター*に配置する必要があります。
`k3s-upgrade`イメージがどのようにアップグレードを実行するかについての詳細は、アップストリームドキュメントを参照してください。
32.2.5.2 概要 #
managementクラスターノードのKubernetesディストリビューションのアップグレードは、`Fleet`と`System Upgrade Controller (SUC)`を利用して行われます。
`Fleet`は、目的のクラスターに`SUC plans`をデプロイおよび管理するために使用されます。
`SUC plans`は、特定のタスクを一連のノードで実行するために*SUC*が従うべき手順を記述したカスタムリソースです。`SUC plan`の例については、アップストリームリポジトリを参照してください。
K8s SUC plans`は、 GitRepoまたは Bundleリソースを特定のFleet workspaceにデプロイすることで、各クラスターにデプロイされます。Fleetはデプロイされた`GitRepo/Bundle`を取得し、その内容（`K8s SUC plans）を目的のクラスター（複数可）にデプロイします。
`GitRepo/Bundle`リソースは常に`management cluster`にデプロイされます。`GitRepo`リソースと`Bundle`リソースのどちらを使用するかはユースケースによって異なります。詳細についてはSection 32.2.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 32.2.5.1.1, “rke2-upgrade”)またはk3s-upgrade (Section 32.2.5.1.2, “k3s-upgrade”)コンテナイメージのいずれかを実行するPodを作成します。
作成されたPodは、以下のワークフローに従います。
ノード上の既存の`rke2/k3s`バイナリを、`rke2-upgrade/k3s-upgrade`イメージから取得したものに置き換えます。
実行中の`rke2/k3s`プロセスを停止します。
`rke2/k3s`プロセスを停止すると再起動がトリガーされ、更新されたバイナリを実行する新しいプロセスが起動し、その結果、Kubernetesディストリビューションはアップグレードされたバージョンになります。
上記の説明の図を以下に示します。
32.2.5.3 要件 #
Kubernetesディストリビューションをバックアップしてください:
*RKE2クラスター*については、RKE2 バックアップおよびリストアのドキュメントを参照してください。
*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" ...
32.2.5.4 K8sアップグレード - SUCプランのデプロイメント #
この手順を使用して以前にアップグレードされた環境の場合、ユーザーは以下の*いずれかの*手順が完了していることを確認する必要があります。
Remove any previously deployed SUC Plans related to older Edge release versions from the management cluster- 既存の`GitRepo/Bundle`target configurationから目的のクラスターを削除するか、`GitRepo/Bundle`リソース自体を削除することで実行できます。Reuse the existing GitRepo/Bundle resource- リソースのリビジョンを、目的の`suse-edge/fleet-examples`releaseに適したフリートを保持する新しいタグに向けることで実行できます。
これは、古いEdgeリリースバージョンの`SUC Plans`との競合を避けるために行われます。
ユーザーがアップグレードを試みた際に、managementクラスター上に既存の`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 32.2.5.2, “概要”で述べたように、Kubernetesのアップグレードは、以下のいずれかの方法で目的のクラスターに`SUC plans`を配布することによって行われます。
Fleet GitRepo リソース (Section 32.2.5.4.1, “SUCプランのデプロイ - GitRepoリソース”)
Fleet Bundle リソース (Section 32.2.5.4.2, “SUCプランのデプロイ - バンドルリソース”)
どのリソースを使用すべきかを判断するには、Section 32.2.2, “ユースケースの特定”を参照してください。
サードパーティのGitOpsツールから`K8s SUC plans`をデプロイしたいユースケースについては、Section 32.2.5.4.3, “SUC プランの展開 - サードパーティの GitOps ワークフロー”を参照してください。
32.2.5.4.1 SUCプランのデプロイ - GitRepoリソース #
必要な`K8s SUC plans`を配布する*GitRepo*リソースは、以下のいずれかの方法でデプロイできます。
Rancher UI- Section 32.2.5.4.1.1, “GitRepoの作成 - Rancher UI” を通じて（`Rancher`が利用可能な場合）。management clusterにリソースを 手動でデプロイ (Section 32.2.5.4.1.2, “GitRepoの作成 - 手動”) することによって。
デプロイ後、ターゲットクラスターのノードのKubernetesアップグレードプロセスを監視するには、Section 18.3, “System Upgrade Controllerプランの監視” を参照してください。
32.2.5.4.1.1 GitRepoの作成 - Rancher UI #
Rancher UIを通じて GitRepo リソースを作成するには、公式の ドキュメント に従ってください。
Edgeチームは、RKE2 および K3s のKubernetesディストリビューション向けに、すぐに使用できるフリート（Fleet）を維持しています。環境に応じて、このフリートを直接使用することも、テンプレートとして使用することもできます。
これらのフリートに同梱されている SUC plans にカスタム変更を含める必要がないユースケースでは、ユーザーは suse-edge/fleet-examples リポジトリから直接フリートを参照できます。
カスタム変更が必要な場合（カスタムTolerationを追加する場合など）、ユーザーは別のリポジトリからフリートを参照する必要があります。これにより、必要に応じてSUCプランに変更を加えることができます。
suse-edge/fleet-examples リポジトリのフリートを使用した GitRepo リソースの設定例：
32.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.6.1/gitrepos/day2/rke2-upgrade-gitrepo.yamlK3s クラスターの場合：
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`セクションを削除します。これはダウンストリームクラスターにのみ必要です。
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*リソースを`management cluster`に適用します。
# RKE2 kubectl apply -f rke2-upgrade-gitrepo.yaml # K3s kubectl apply -f k3s-upgrade-gitrepo.yaml作成された*GitRepo*リソースを`fleet-local`名前空間の下で表示します。
# 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
32.2.5.4.2 SUCプランのデプロイ - バンドルリソース #
必要な`Kubernetes upgrade SUC Plans`を出荷する*Bundle*リソースは、以下のいずれかの方法でデプロイできます。
Rancher UI- Section 32.2.5.4.2.1, “バンドルの作成 - Rancher UI” を通じて（`Rancher`が利用可能な場合）。management clusterにリソースを 手動でデプロイ (Section 32.2.5.4.2.2, “バンドルの作成 - 手動”) することによって。
デプロイ後、ターゲットクラスターのノードのKubernetesアップグレードプロセスを監視するには、Section 18.3, “System Upgrade Controllerプランの監視” を参照してください。
32.2.5.4.2.1 バンドルの作成 - Rancher UI #
Edgeチームは、rke2およびk3sの両方のKubernetesディストリビューションですぐに使用できるバンドルを維持管理しています。環境に応じて、これらのバンドルを直接使用することも、テンプレートとして使用することもできます。
RancherのUIからバンドルを作成するには、以下の手順を実行します。
左上隅にある*☰ → Continuous Delivery*をクリックします。
Advanced > *Bundles*に移動します。
*Create from YAML*を選択します。
ここから、以下のいずれかの方法でバンドルを作成できます。
Noteバンドルが出荷する`SUC plans`にカスタム変更を含める必要があるユースケースがあるかもしれません（例：カスタムのtolerationsを追加する場合など）。以下の手順で生成されるバンドルに、これらの変更が含まれていることを確認してください。
`suse-edge/fleet-examples`からRKE2またはK3sのバンドルコンテンツを、*Create from YAML*ページに手動でコピーします。
目的の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*ページにバンドルコンテンツが自動入力されます。
Rancher UIでバンドルを編集します。
Bundle`の*ネームスペース*を変更して、fleet-local`ネームスペースを指すようにします。# Example kind: Bundle apiVersion: fleet.cattle.io/v1alpha1 metadata: name: rke2-upgrade namespace: fleet-local ...Bundle`の*target*クラスターを変更して、`local（管理）クラスターを指すようにします。spec: targets: - clusterName: localNote`local`クラスターの名前が異なる場合があるユースケースがいくつかあります。
`local`クラスター名を取得するには、以下のコマンドを実行します。
kubectl get clusters.fleet.cattle.io -n fleet-local
*Create*を選択します。
32.2.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.yamlK3s クラスターの場合：
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`設定を編集します。
Bundle`の*target*クラスターを変更して、`local（管理）クラスターを指すようにします。spec: targets: - clusterName: localNote`local`クラスターの名前が異なる場合があるユースケースがいくつかあります。
`local`クラスター名を取得するには、以下のコマンドを実行します。
kubectl get clusters.fleet.cattle.io -n fleet-localBundle`の*ネームスペース*を変更して、fleet-local`ネームスペースを指すようにします。# Example kind: Bundle apiVersion: fleet.cattle.io/v1alpha1 metadata: name: rke2-upgrade namespace: fleet-local ...
`management cluster`に*Bundle*リソースを適用します。
# For RKE2 kubectl apply -f rke2-plan-bundle.yaml # For K3s kubectl apply -f k3s-plan-bundle.yamlfleet-local名前空間の下で作成された Bundle リソースを表示します。# 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
32.2.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.yamlworkerノード用 -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.yamlworkerノード用 -fleets/day2/system-upgrade-controller-plans/k3s-upgrade/plan-worker.yaml
これらの Plan リソースは System Upgrade Controller によって解釈され、アップグレードする各ダウンストリームクラスターに展開する必要があります。SUC 展開に関する情報については、Section 18.2, “System Upgrade Controllerのインストール”を参照してください。
Kubernetes バージョンアップグレードのために SUC Plans をデプロイする GitOps ワークフローをより深く理解するには、Fleet を用いた更新手順の overview (Section 32.2.5.2, “概要”) を確認することが有益です。
32.2.6 Helmチャートのアップグレード #
このセクションでは、次の部分について説明します。
Section 32.2.6.1, “エアギャップ(された)環境の準備” - Edge関連のOCIチャートおよびイメージをプライベートレジストリに配布する方法に関する情報が記載されています。
Section 32.2.6.2, “アップグレード手順” - さまざまなHelmチャートアップグレードのユースケースと、そのアップグレード手順に関する情報が記載されています。
32.2.6.1 エアギャップ(された)環境の準備 #
32.2.6.1.1 HelmチャートFleetにアクセスできることを確認してください。 #
環境のサポート状況に応じて、次のいずれかのオプションを選択できます。
`management cluster`からアクセス可能なローカルGitサーバーで、チャートのFleetリソースをホストします。
FleetのCLIを使用して、HelmチャートをBundleに変換します。これにより、直接使用できるようになり、どこかでホストする必要がなくなります。FleetのCLIは、リリースページから取得できます。Macユーザーの場合は、fleet-cli Homebrew Formulaeが用意されています。
32.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リリースに関連するイメージのリストが含まれています。
32.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`という名前のロード可能なアーカイブが作成されます。
Note`-i|--images`オプションが指定されている場合、アーカイブの名前が異なることがあります。
このアーカイブを*エアギャップ(された)*マシンにコピーします：
scp edge-images.tar.gz <user>@<machine_ip>:/path
32.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`という名前のアーカイブが作成されます。
Note`-a|--archive`オプションが指定されている場合、アーカイブの名前が異なることがあります。
このアーカイブを*エアギャップ(された)*マシンにコピーします：
scp oci-artefacts.tar.gz <user>@<machine_ip>:/path
32.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.gzNoteこれにより、
edge-images.tar.gz`からすべてのイメージがロードされ、タグが付け直されて、--registry`オプションで指定されたレジストリにプッシュされます。
32.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チャートイメージをプライベートレジストリにロードします：
./edge-load-oci-artefacts.sh --archive-directory edge-release-oci-tgz-<date> --registry <REGISTRY.YOURDOMAIN.COM:PORT> --source-registry registry.suse.com
32.2.6.1.7 Kubernetesディストリビューションでプライベートレジストリを設定します。 #
RKE2については、Private Registry Configurationを参照してください。
K3sについては、Private Registry Configurationを参照してください。
32.2.6.2 アップグレード手順 #
このセクションでは、次のHelmアップグレード手順のユースケースについて説明します。
手動でデプロイされたHelmチャートは、確実にアップグレードすることはできません。Section 32.2.6.2.1, “新しいクラスターがあり、Edge Helmチャートをデプロイおよび管理したい場合”メソッドを使用してHelmチャートを再デプロイすることをお勧めします。
32.2.6.2.1 新しいクラスターがあり、Edge Helmチャートをデプロイおよび管理したい場合 #
このセクションでは、次の方法について説明します。
32.2.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を参照してください。
場合によっては、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`チャートのデプロイメントガイドラインとして扱うべきでは*ありません*。
32.2.6.2.1.2 チャートのFleetをデプロイする #
GitRepo (Section 32.2.6.2.1.2.1, “GitRepo”)またはBundle (Section 32.2.6.2.1.2.2, “バンドル”)のいずれかを使用して、チャートのFleetをデプロイできます。
Fleetのデプロイ中に`Modified`メッセージが表示された場合は、対応する`comparePatches`エントリをFleetの`diff`セクションに必ず追加してください。詳細については、変更されたGitRepoを無視するためのDiffの生成を参照してください。
32.2.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-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_url32.2.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`に手動でデプロイする方法の例を示します。
longhornチャートFleetテンプレートに移動します：
cd fleets/day2/chart-templates/longhorn/longhornFleetがHelmチャートをデプロイすべきクラスターを指示する`targets.yaml`ファイルを作成します。
cat > targets.yaml <<EOF targets: # Match your local (management) cluster - clusterName: local EOFNoteローカルクラスタの名前が異なる場合があるユースケースがいくつか存在します。
ローカルクラスタ名を取得するには、以下のコマンドを実行します。
kubectl get clusters.fleet.cattle.io -n fleet-localfleet-cliを使用して、
LonghornHelmチャートFleetをBundleリソースに変換します。NoteFleetのCLIは、リリース*アセット*ページ（
fleet-linux-amd64）から取得できます。Macユーザー向けには、fleet-cliのHomebrew Formulaeが用意されています。
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をBundleリソースに変換します。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`ファイルを`management cluster`にデプロイします。
kubectl apply -f longhorn-crd-bundle.yaml kubectl apply -f longhorn-bundle.yaml
これらの手順に従うことで、指定されたすべてのmanagementクラスターに`SUSE Storage`が確実にデプロイされます。
32.2.6.2.1.3 デプロイされたHelmチャートを管理する #
Fleetでデプロイした後、HelmチャートのアップグレードについてはSection 32.2.6.2.2, “Fleetで管理されているHelmチャートをアップグレードしたい”を参照してください。
32.2.6.2.2 Fleetで管理されているHelmチャートをアップグレードしたい #
目的のEdgeリリースと互換性を持たせるために、チャートをアップグレードする必要があるバージョンを決定します。EdgeリリースごとのHelmチャートバージョンは、リリースノート (Chapter 41, リリースノート)から確認できます。
Fleetで監視されているGitリポジトリで、Helmチャートの`fleet.yaml`ファイルを編集し、リリースノート (Chapter 41, リリースノート)から正しいチャートの*バージョン*と*リポジトリ*を指定します。
変更をコミットしてリポジトリにプッシュすると、目的のHelmチャートのアップグレードがトリガーされます。
32.2.6.2.3 EIB経由でデプロイされたHelmチャートをアップグレードしたい #
Chapter 8, Edge Image Builderは、`HelmChart`リソースを作成し、RKE2/K3s Helm統合機能によって導入された`helm-controller`を利用することで、Helmチャートをデプロイします。
`EIB`経由でデプロイされたHelmチャートが確実にアップグレードされるように、ユーザーはそれぞれの`HelmChart`リソースに対してアップグレードを行う必要があります。
以下の情報をご覧ください。
アップグレードプロセスの一般的な概要 (Section 32.2.6.2.3.1, “概要”)。
必要なアップグレード手順 (Section 32.2.6.2.3.2, “アップグレード手順”)。
説明した方法を使用してLonghornチャートのアップグレードを示す例 (Section 32.2.6.2.3.3, “例”)。
別のGitOpsツール (Section 32.2.6.2.3.4, “サードパーティのGitOpsツールを使用したHelmチャートのアップグレード”)でアップグレードプロセスを使用する方法。
32.2.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の助けを借りて、そのリソースを目的のmanagementクラスターに配布します。
これらのリソースには以下が含まれます。
*ユーザー提供*のHelmチャートデータを保持する`Secrets`のセット。
前述の`Secrets`をマウントし、それに基づいて対応するHelmChartリソースをパッチする`Pod`をデプロイする`Kubernetes Job`。
前述の通り、これにより`helm-controller`がトリガーされ、実際のHelmチャートのアップグレードが実行されます。
上記の説明の図を以下に示します。
32.2.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サーバーのサポートが許可されている場合）の場合：
GitOpsに使用するリポジトリに`fleets/day2/eib-charts-upgrader` Fleetをコピーします。
Note`generate-chart-upgrade-data.sh`スクリプトによって行われた変更がFleetに含まれていることを確認してください。
eib-charts-upgraderFleetのすべてのリソースを配送するために使用される`GitRepo`リソースを設定します。Rancher UIを通じた`GitRepo`の設定とデプロイについては、Rancher UIでのFleetへのアクセスを参照してください。
`GitRepo`の手動設定とデプロイについては、デプロイの作成を参照してください。
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 EOFNotelocalクラスターの名前が異なる場合がある使用事例がいくつかあります。localクラスター名を取得するには、以下のコマンドを実行します。kubectl get clusters.fleet.cattle.io -n fleet-localfleet-cliを使用して、Fleet をBundleリソースに変換します。fleet apply --compress --targets-file=targets.yaml -n fleet-local -o - eib-charts-upgrade > bundle.yamlこれにより、
eib-charts-upgraderFleet からのすべてのテンプレート化されたリソースを保持する Bundle (bundle.yaml) が作成されます。fleet applyコマンドの詳細については、「fleet apply」を参照してください。Fleet を Bundle に変換する方法の詳細については、「Convert a Helm Chart into a Bundle」を参照してください。
Bundleをデプロイする。これには、次の2つの方法があります。Rancher の UI を使用する場合 - 継続的デリバリ → Advanced → Bundles → Create from YAML に移動し、
bundle.yamlの内容を貼り付けるか、Read from Fileオプションをクリックしてファイル自体を渡します。手動 -
bundle.yamlファイルを`management cluster`内にデプロイします。
これらの手順を実行すると、GitRepo/Bundle リソースが正常にデプロイされます。このリソースは Fleet によって取得され、その内容はユーザーが前の手順で指定したターゲットクラスターにデプロイされる。この処理の概要については、「Section 32.2.6.2.3.1, “概要”」を参照してください。
アップグレードの処理を追跡する方法については、Section 32.2.6.2.3.3, “例” を参照してください。
チャートのアップグレードが正常に確認できたら、Bundle/GitRepo リソースを削除する。
これにより、不要になったアップグレードリソースを management クラスターから削除することで、将来的なバージョン競合の発生を防ぐことができます。
32.2.6.2.3.3 例 #
以下の例は、EIB を介してデプロイされた Helm チャートを management クラスター上で別のバージョンにアップグレードする方法を示しています。この例で使用されているバージョンは*推奨されているものではありません*のでご注意ください。Edge リリース固有の推奨バージョンについては、「リリースノート (Chapter 41, リリースノート)」を参照してください。
使用事例:
`management`クラスターで、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`は*エアギャップ(された)*であり、ローカルGitサーバーのサポートがなく、Rancherが正常にセットアップされていると想定されます。
アップグレード手順 (Section 32.2.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.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.yamlBundleFleet用の`eib-charts-upgrader`を作成します。まず、Fleet自体に移動します。
cd ./fleet-examples/fleets/day2/eib-charts-upgrader次に、`targets.yaml`ファイルを作成します。
cat > targets.yaml <<EOF targets: - clusterName: local EOF次に、`fleet-cli`バイナリを使用してFleetをBundleに変換します。
fleet apply --compress --targets-file=targets.yaml -n fleet-local -o - eib-charts-upgrade > bundle.yaml
Rancher UIからBundleをデプロイします：
Figure 32.1: Rancher UIからBundleをデプロイする #ここから、*Read from File*を選択し、システム上の`bundle.yaml`ファイルを見つけます。
これにより、RancherのUI内で`Bundle`が自動的に入力されます。
［Create］を選択します。
デプロイが成功すると、Bundleは次のようになります：
Figure 32.2: Bundleのデプロイに成功しました #
`Bundle`のデプロイが成功した後、アップグレードの処理を監視するには：
`Upgrade Pod`のログを確認します：
次に、helm-controllerによってアップグレード用に作成されたPodのログを確認します：
Pod名は次のテンプレートになります -
helm-install-longhorn-<random-suffix>Podは、`HelmChart`リソースがデプロイされたネームスペースに配置されます。今回の場合は`kube-system`です。
Figure 32.3: 正常にアップグレードされたLonghornチャートのログ #
Rancherの`HelmCharts`セクション（
More Resources → HelmCharts）に移動して、`HelmChart`のバージョンが更新されていることを確認します。チャートがデプロイされたネームスペースを選択します。この例では`kube-system`になります。最後に、Longhorn Podが実行されていることを確認します。
上記の検証を行った後、Longhorn Helmチャートが`1.11.2`バージョンにアップグレードされたと判断して問題ありません。
32.2.6.2.3.4 サードパーティのGitOpsツールを使用したHelmチャートのアップグレード #
Fleet以外のGitOpsワークフロー（例：Flux）でこのアップグレード手順を使用したいというユースケースがあるかもしれません。
アップグレード手順に必要なリソースを作成するには、generate-chart-upgrade-data.sh スクリプトを使用して、ユーザーが提供したデータで eib-charts-upgrader Fleet を設定できます。この方法の詳細については、Section 32.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 セットアップを設定できるようにすることを忘れないでください。
このワークフローの使用方法を理解するには、Section 32.2.6.2.3.1, “概要” と Section 32.2.6.2.3.2, “アップグレード手順” を参照すると役立ちます。