Hosted Control Plane
OpenShift Container Platform で Hosted Control Plane を使用する
概要
第1章 Hosted Control Plane の概要 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターは、スタンドアロンまたは Hosted Control Plane という 2 つの異なるコントロールプレーン設定を使用してデプロイできます。スタンドアロン構成では、専用の仮想マシンまたは物理マシンを使用してコントロールプレーンをホストします。OpenShift Container Platform のホステッドコントロールプレーンを使用すると、コントロールプレーンごとに専用の仮想または物理マシンを必要とせずに、ホスティングクラスター上にコントロールプレーンを Pod として作成できます。
1.1. ホストされたコントロールプレーンの概要 (テクノロジープレビュー) リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Container Platform のホストされたコントロールプレーンを、管理コストの削減、クラスターのデプロイ時間の最適化、管理とワークロードの問題の分離に使用することで、アプリケーションに集中できます。
ホストされたコントロールプレーンをテクノロジープレビュー機能として有効にするには、Amazon Web Services (AWS) 上の Kubernetes Operator バージョン 2.0 以降のマルチクラスターエンジン、エージェントプロバイダーを使用したベアメタル、または OpenShift Virtualization を使用します。
ホストされたコントロールプレーンは、テクノロジープレビュー機能としてのみ利用できます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
1.1.1. ホストされたコントロールプレーンのアーキテクチャー リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、多くの場合、クラスターがコントロールプレーンとデータプレーンで構成される結合モデルまたはスタンドアロンモデルでデプロイされます。コントロールプレーンには、API エンドポイント、ストレージエンドポイント、ワークロードスケジューラー、および状態を保証するアクチュエーターが含まれます。データプレーンには、ワークロードとアプリケーションが実行されるコンピュート、ストレージ、およびネットワークが含まれます。
スタンドアロンコントロールプレーンは、クォーラムを確保できる最小限の数で、物理または仮想のノードの専用グループによってホストされます。ネットワークスタックは共有されます。クラスターへの管理者アクセスにより、クラスターのコントロールプレーン、マシン管理 API、およびクラスターの状態に影響を与える他のコンポーネントを可視化できます。
スタンドアロンモデルは正常に機能しますが、状況によっては、コントロールプレーンとデータプレーンが分離されたアーキテクチャーが必要になります。そのような場合には、データプレーンは、専用の物理ホスティング環境がある別のネットワークドメインに配置されています。コントロールプレーンは、Kubernetes にネイティブなデプロイやステートフルセットなど、高レベルのプリミティブを使用してホストされます。コントロールプレーンは、他のワークロードと同様に扱われます。
1.1.2. Hosted Control Plane の利点 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform の Hosted Control Plane を使用すると、真のハイブリッドクラウドアプローチへの道が開かれ、その他のさまざまなメリットも享受できます。
- コントロールプレーンが分離され、専用のホスティングサービスクラスターでホストされるため、管理とワークロードの間のセキュリティー境界が強化されます。その結果、クラスターのクレデンシャルが他のユーザーに漏洩する可能性が低くなります。インフラストラクチャーのシークレットアカウント管理も分離されているため、クラスターインフラストラクチャーの管理者が誤ってコントロールプレーンインフラストラクチャーを削除することはありません。
 - Hosted Control Plane を使用すると、より少ないノードで多数のコントロールプレーンを実行できます。その結果、クラスターはより安価になります。
 - コントロールプレーンは OpenShift Container Platform で起動される Pod で構成されるため、コントロールプレーンはすぐに起動します。同じ原則が、モニタリング、ロギング、自動スケーリングなどのコントロールプレーンとワークロードに適用されます。
 - インフラストラクチャーの観点からは、レジストリー、HAProxy、クラスター監視、ストレージノードなどのインフラストラクチャーをテナントのクラウドプロバイダーのアカウントにプッシュして、テナントでの使用を分離できます。
 - 運用上の観点からは、マルチクラスター管理はさらに集約され、クラスターの状態と一貫性に影響を与える外部要因が少なくなります。Site Reliability Engineer は、一箇所で問題をデバッグして、クラスターのデータプレインを移動するため、解決までの時間 (TTR) が短縮され、生産性が向上します。
 
1.2. Hosted Control Plane、multicluster engine Operator、および RHACM の関係 リンクのコピーリンクがクリップボードにコピーされました!
Hosted Control Plane は、multicluster engine for Kubernetes Operator を使用して設定できます。マルチクラスターエンジンは Red Hat Advanced Cluster Management (RHACM) の不可欠な要素であり、RHACM ではデフォルトで有効になっています。multicluster engine Operator のクラスターライフサイクルにより、さまざまなインフラストラクチャークラウドプロバイダー、プライベートクラウド、オンプレミスデータセンターにおける Kubernetes クラスターの作成、インポート、管理、破棄のプロセスが定義されます。
multicluster engine Operator は、OpenShift Container Platform および RHACM ハブクラスターにクラスター管理機能を提供するクラスターライフサイクル Operator です。multicluster engine Operator は、クラスター群の管理を強化し、クラウドとデータセンター全体の OpenShift Container Platform クラスターのライフサイクル管理を支援します。
図1.1 クラスターライフサイクルと基盤
OpenShift Container Platform の multicluster engine Operator は、スタンドアロンクラスターマネージャーとして、または RHACM ハブクラスターの一部として使用できます。
管理クラスターはホスティングクラスターとも呼ばれます。
OpenShift Container Platform クラスターは、スタンドアロンまたは Hosted Control Plane という 2 つの異なるコントロールプレーン設定を使用してデプロイできます。スタンドアロン設定では、専用の仮想マシンまたは物理マシンを使用してコントロールプレーンをホストします。OpenShift Container Platform の Hosted Control Plane を使用すると、各コントロールプレーンに専用の仮想マシンまたは物理マシンを用意する必要なく、管理クラスター上の Pod としてコントロールプレーンを作成できます。
図1.2 RHACM と multicluster engine Operator の概要図
1.3. ホストされたコントロールプレーンのバージョン管理 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform のメジャー、マイナー、またはパッチバージョンのリリースごとに、 Hosted Control Plane の 2 つのコンポーネントがリリースされます。
- HyperShift Operator
 - コマンドラインインターフェイス (CLI)
 
				HyperShift Operator は、HostedCluster API リソースによって表されるホストされたクラスターのライフサイクルを管理します。HyperShift Operator は、OpenShift Container Platform の各リリースでリリースされます。HyperShift Operator をインストールすると、次の例に示すように、HyperShift namespace に supported-versions という config map が作成されます。config map は、デプロイできる HostedCluster のバージョンを示しています。
			
CLI は、開発目的のヘルパーユーティリティーです。CLI は、HyperShift Operator リリースの一部としてリリースされます。互換性ポリシーは保証されません。
				API である hypershift.openshift.io は、軽量で柔軟な異種の OpenShift Container Platform クラスターを大規模に作成および管理する方法を提供します。この API は、HostedCluster と NodePool という 2 つのユーザー向けリソースを公開します。HostedCluster リソースは、コントロールプレーンと共通データプレーンの設定をカプセル化します。HostedCluster リソースを作成すると、ノードが接続されていない、完全に機能するコントロールプレーンが作成されます。NodePool リソースは、HostedCluster リソースにアタッチされたスケーラブルなワーカーノードのセットです。
			
API バージョンポリシーは、通常、Kubernetes API のバージョン管理 のポリシーと一致します。
第2章 ホステッドコントロールプレーンの設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform のホストされたコントロールプレーンの使用を開始するには、まず、使用するプロバイダーでホストされたクラスターを設定します。次に、いくつかの管理タスクを完了します。
Hosted Control Plane は、テクノロジープレビュー機能としてのみ利用できます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
次のプロバイダーのいずれかを選択して、手順を表示できます。
2.1. Amazon Web Services (AWS) リンクのコピーリンクがクリップボードにコピーされました!
- AWS でホストクラスターを設定 (テクノロジープレビュー): AWS でホストされたクラスターを設定するタスクには、AWS S3 OIDC シークレットの作成、ルーティング可能なパブリックゾーンの作成、外部 DNS の有効化、AWS PrivateLink の有効化、ホストされたコントロールプレーン機能の有効化、およびホストされたコントロールプレーン CLI のインストールが含まれます。
 - AWS でのホストされたコントロールプレーンクラスターの管理 (テクノロジープレビュー): 管理タスクには、AWS でのホストされたクラスターの作成、インポート、アクセス、または削除が含まれます。
 
2.2. ベアメタル リンクのコピーリンクがクリップボードにコピーされました!
- ベアメタルでのホストクラスターの設定 (テクノロジープレビュー): ホストクラスターを作成する前に DNS を設定します。
 - 
						ベアメタル上のホストされたコントロールプレーンクラスターの管理 (テクノロジープレビュー): ホストされたクラスターの作成、
InfraEnvリソースの作成、エージェントの追加、ホストされたクラスターへのアクセス、NodePoolオブジェクトのスケーリング、Ingress の処理、ノードの自動スケーリングの有効化、またはホストされたクラスターの削除。 
2.3. OpenShift Virtualization リンクのコピーリンクがクリップボードにコピーされました!
- OpenShift Virtualization 上でのホストされたコントロールプレーンクラスターの管理 (テクノロジープレビュー): KubeVirt 仮想マシンによってホストされたワーカーノードを使用して OpenShift Container Platform クラスターを作成します。
 
第3章 Hosted Control Plane の管理 リンクのコピーリンクがクリップボードにコピーされました!
Hosted Control Plane 用に環境を設定し、ホストされたクラスターを作成したら、クラスターとノードをさらに管理できます。
Hosted Control Plane は、テクノロジープレビュー機能としてのみ利用できます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
3.1. ホストされたコントロールプレーンの更新 リンクのコピーリンクがクリップボードにコピーされました!
ホストされたコントロールプレーンの更新には、ホストされたクラスターとノードプールの更新が含まれます。更新プロセス中にクラスターが完全に動作し続けるためには、コントロールプレーンとノードの更新を完了する際に、Kubernetes バージョンスキューポリシー の要件を満たす必要があります。
3.1.1. ホストされたクラスターの更新 リンクのコピーリンクがクリップボードにコピーされました!
					spec.release 値は、コントロールプレーンのバージョンを決定します。HostedCluster オブジェクトは、意図した spec.release 値を HostedControlPlane.spec.release 値に送信し、適切な Control Plane Operator のバージョンを実行します。
				
Hosted Control Plane は、新しいバージョンの Cluster Version Operator (CVO) により、新しいバージョンのコントロールプレーンコンポーネントと OpenShift Container Platform コンポーネントのロールアウトを管理します。
3.1.2. ノードプールの更新 リンクのコピーリンクがクリップボードにコピーされました!
					ノードプールを使用すると、spec.release および spec.config の値を公開することで、ノードで実行されているソフトウェアを設定できます。次の方法でノードプールのローリング更新を開始できます。
				
- 
							
spec.releaseまたはspec.configの値を変更します。 - AWS インスタンスタイプなどのプラットフォーム固有のフィールドを変更します。結果は、新しいタイプの新規インスタンスのセットになります。
 - クラスター設定を変更します (変更がノードに伝播される場合)。
 
					ノードプールは、replace 更新とインプレース更新をサポートします。nodepool.spec.release 値は、特定のノードプールのバージョンを決定します。NodePool オブジェクトは、.spec.management.upgradeType 値に従って、置換またはインプレースローリング更新を完了します。
				
ノードプールを作成した後は、更新タイプは変更できません。更新タイプを変更する場合は、ノードプールを作成し、他のノードプールを削除する必要があります。
3.1.2.1. ノードプールの replace 更新 リンクのコピーリンクがクリップボードにコピーされました!
置き換え 更新では、以前のバージョンから古いインスタンスが削除され、新しいバージョンでインスタンスが作成されます。この更新タイプは、このレベルの不変性がコスト効率に優れているクラウド環境で効果的です。
replace 更新では、ノードが完全に再プロビジョニングされるため、手動による変更は一切保持されません。
3.1.2.2. ノードプールのインプレース更新 リンクのコピーリンクがクリップボードにコピーされました!
インプレース 更新では、インスタンスのオペレーティングシステムが直接更新されます。このタイプは、ベアメタルなど、インフラストラクチャーの制約が高い環境に適しています。
インプレース更新では手動による変更を保存できますが、kubelet 証明書など、クラスターが直接管理するファイルシステムまたはオペレーティングシステムの設定に手動で変更を加えると、エラーが報告されます。
3.2. Hosted Control Plane のノードプールの更新 リンクのコピーリンクがクリップボードにコピーされました!
Hosted Control Plane では、ノードプールを更新して OpenShift Container Platform のバージョンを更新します。ノードプールのバージョンは、ホストされているコントロールプレーンのバージョンを超えないものとします。
手順
OpenShift Container Platform の新しいバージョンに更新するプロセスを開始するには、以下のコマンドを入力してノードプールの
spec.release.image値を変更します。oc -n NAMESPACE patch HC HCNAME --patch '{"spec":{"release":{"image": "example"}}}' --type=merge$ oc -n NAMESPACE patch HC HCNAME --patch '{"spec":{"release":{"image": "example"}}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 
検証
- 
						新しいバージョンがロールアウトされたことを確認するには、
.status.version値とステータス条件を確認します。 
3.3. ホストされたコントロールプレーンのノードプールの設定 リンクのコピーリンクがクリップボードにコピーされました!
				ホストされたコントロールプレーンでは、管理クラスターの config map 内に MachineConfig オブジェクトを作成することでノードプールを設定できます。
			
手順
管理クラスターの config map 内に
MachineConfigオブジェクトを作成するには、次の情報を入力します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
 MachineConfigオブジェクトが保存されているノード上のパスを設定します。
オブジェクトを config map に追加した後、次のように config map をノードプールに適用できます。
$ oc edit nodepool <nodepool_name> --namespace <hosted_cluster_namespace>
$ oc edit nodepool <nodepool_name> --namespace <hosted_cluster_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow 
3.4. ホストされたクラスターにおけるノードのチューニング設定 リンクのコピーリンクがクリップボードにコピーされました!
ホストされたコントロールプレーンは、テクノロジープレビュー機能としてのみ利用できます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
				ホストされたクラスター内のノードでノードレベルのチューニングを設定するには、Node Tuning Operator を使用できます。ホストされたコントロールプレーンでは、Tuned オブジェクトを含む config map を作成し、ノードプールでそれらの config map を参照することで、ノードのチューニングを設定できます。
			
手順
チューニングされた有効なマニフェストを含む config map を作成し、ノードプールでマニフェストを参照します。次の例で
Tunedマニフェストは、任意の値を持つtuned-1-node-labelノードラベルを含むノード上でvm.dirty_ratioを 55 に設定するプロファイルを定義します。次のConfigMapマニフェストをtuned-1.yamlという名前のファイルに保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記Tuned 仕様の
spec.recommendセクションのエントリーにラベルを追加しない場合は、ノードプールベースのマッチングが想定されるため、spec.recommendセクションの最も優先度の高いプロファイルがプール内のノードに適用されます。Tuned.spec.recommend.matchセクションでラベル値を設定することにより、よりきめ細かいノードラベルベースのマッチングを実現できますが、ノードプールの.spec.management.upgradeType値をInPlaceに設定しない限り、ノードラベルはアップグレード中に保持されません。管理クラスターに
ConfigMapオブジェクトを作成します。oc --kubeconfig="$MGMT_KUBECONFIG" create -f tuned-1.yaml
$ oc --kubeconfig="$MGMT_KUBECONFIG" create -f tuned-1.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ノードプールを編集するか作成して、ノードプールの
spec.tuningConfigフィールドでConfigMapオブジェクトを参照します。この例では、2 つのノードを含むnodepool-1という名前のNodePoolが 1 つだけあることを前提としています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記複数のノードプールで同じ config map を参照できます。Hosted Control Plane では、Node Tuning Operator が Tuned CR の名前にノードプール名と namespace のハッシュを追加して、それらを区別します。この場合を除き、同じホステッドクラスターの異なる Tuned CR に、同じ名前の複数の TuneD プロファイルを作成しないでください。
検証
					Tuned マニフェストを含む ConfigMap オブジェクトを作成し、それを NodePool で参照したことで、Node Tuning Operator により Tuned オブジェクトがホステッドクラスターに同期されます。どの Tuned オブジェクトが定義されているか、どの TuneD プロファイルが各ノードに適用されているかを確認できます。
				
ホステッドクラスター内の
Tunedオブジェクトをリスト表示します。oc --kubeconfig="$HC_KUBECONFIG" get tuned.tuned.openshift.io -n openshift-cluster-node-tuning-operator
$ oc --kubeconfig="$HC_KUBECONFIG" get tuned.tuned.openshift.io -n openshift-cluster-node-tuning-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME AGE default 7m36s rendered 7m36s tuned-1 65s
NAME AGE default 7m36s rendered 7m36s tuned-1 65sCopy to Clipboard Copied! Toggle word wrap Toggle overflow ホステッドクラスター内の
Profileオブジェクトをリスト表示します。oc --kubeconfig="$HC_KUBECONFIG" get profile.tuned.openshift.io -n openshift-cluster-node-tuning-operator
$ oc --kubeconfig="$HC_KUBECONFIG" get profile.tuned.openshift.io -n openshift-cluster-node-tuning-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME TUNED APPLIED DEGRADED AGE nodepool-1-worker-1 tuned-1-profile True False 7m43s nodepool-1-worker-2 tuned-1-profile True False 7m14s
NAME TUNED APPLIED DEGRADED AGE nodepool-1-worker-1 tuned-1-profile True False 7m43s nodepool-1-worker-2 tuned-1-profile True False 7m14sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記カスタムプロファイルが作成されていない場合は、
openshift-nodeプロファイルがデフォルトで適用されます。チューニングが正しく適用されたことを確認するには、ノードでデバッグシェルを開始し、sysctl 値を確認します。
oc --kubeconfig="$HC_KUBECONFIG" debug node/nodepool-1-worker-1 -- chroot /host sysctl vm.dirty_ratio
$ oc --kubeconfig="$HC_KUBECONFIG" debug node/nodepool-1-worker-1 -- chroot /host sysctl vm.dirty_ratioCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
vm.dirty_ratio = 55
vm.dirty_ratio = 55Copy to Clipboard Copied! Toggle word wrap Toggle overflow 
3.5. ホストされたコントロールプレーン用の SR-IOV Operator のデプロイ リンクのコピーリンクがクリップボードにコピーされました!
ホストされたコントロールプレーンは、テクノロジープレビュー機能としてのみ利用できます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
ホスティングサービスクラスターを設定してデプロイすると、ホストされたクラスターで SR-IOV Operator へのサブスクリプションを作成できます。SR-IOV Pod は、コントロールプレーンではなくワーカーマシンで実行されます。
前提条件
AWS 上でホストされたクラスターを設定およびデプロイしている。詳細は、AWS 上でのホストクラスターの設定 (テクノロジープレビュー) を参照してください。
手順
namespace と Operator グループを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow SR-IOV Operator へのサブスクリプションを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 
検証
SR-IOV Operator の準備ができていることを確認するには、次のコマンドを実行し、結果の出力を表示します。
oc get csv -n openshift-sriov-network-operator
$ oc get csv -n openshift-sriov-network-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME DISPLAY VERSION REPLACES PHASE sriov-network-operator.4.13.0-202211021237 SR-IOV Network Operator 4.13.0-202211021237 sriov-network-operator.4.13.0-202210290517 Succeeded
NAME DISPLAY VERSION REPLACES PHASE sriov-network-operator.4.13.0-202211021237 SR-IOV Network Operator 4.13.0-202211021237 sriov-network-operator.4.13.0-202210290517 SucceededCopy to Clipboard Copied! Toggle word wrap Toggle overflow SR-IOV Pod がデプロイされていることを確認するには、次のコマンドを実行します。
oc get pods -n openshift-sriov-network-operator
$ oc get pods -n openshift-sriov-network-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 
3.6. ホストされたクラスターの削除 リンクのコピーリンクがクリップボードにコピーされました!
ホストされたクラスターを削除する手順は、使用するプロバイダーによって異なります。
手順
- クラスターが AWS にある場合は、AWS でのホストされたクラスターの破棄 の手順に従います。
 - クラスターがベアメタル上にある場合は、ベアメタルでのホストされたクラスターの破棄 の手順に従います。
 - クラスターが OpenShift Virtualization にある場合は、OpenShift Virtualization 上のホストされたクラスターの破棄 の手順に従います。
 
次のステップ
ホステッドコントロールプレーン機能を無効にする場合は、ホストされたコントロールプレーン機能の無効化 を参照してください。
第4章 ホストされたコントロールプレーンのバックアップ、復元、障害復旧 リンクのコピーリンクがクリップボードにコピーされました!
ホストされたクラスターで etcd をバックアップおよび復元する必要がある場合、またはホストされたクラスターの障害復旧を行う必要がある場合は、次の手順を確認してください。
Hosted Control Plane は、テクノロジープレビュー機能としてのみ利用できます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
4.1. ホストされたクラスターでの etcd のバックアップと復元 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform でホストされたコントロールプレーンを使用する場合、etcd をバックアップおよび復元するプロセスは、通常の etcd バックアッププロセス とは異なります。
4.1.1. ホストされたクラスターでの etcd のスナップショットの作成 リンクのコピーリンクがクリップボードにコピーされました!
ホストされたクラスターの etcd をバックアップするプロセスの一環として、etcd のスナップショットを作成します。スナップショットを作成した後、たとえば障害復旧操作の一部として復元できます。
この手順には、API のダウンタイムが必要です。
手順
このコマンドを入力して、ホストされたクラスターの調整を一時停止します。
oc patch -n clusters hostedclusters/${CLUSTER_NAME} -p '{"spec":{"pausedUntil":"'${PAUSED_UNTIL}'"}}' --type=merge$ oc patch -n clusters hostedclusters/${CLUSTER_NAME} -p '{"spec":{"pausedUntil":"'${PAUSED_UNTIL}'"}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドを入力して、すべての etcd-writer デプロイメントを停止します。
oc scale deployment -n ${HOSTED_CLUSTER_NAMESPACE} --replicas=0 kube-apiserver openshift-apiserver openshift-oauth-apiserver$ oc scale deployment -n ${HOSTED_CLUSTER_NAMESPACE} --replicas=0 kube-apiserver openshift-apiserver openshift-oauth-apiserverCopy to Clipboard Copied! Toggle word wrap Toggle overflow 各 etcd コンテナーで
execコマンドを使用して、etcd スナップショットを作成します。oc exec -it etcd-0 -n ${HOSTED_CLUSTER_NAMESPACE} -- env ETCDCTL_API=3 /usr/bin/etcdctl --cacert /etc/etcd/tls/client/etcd-client-ca.crt --cert /etc/etcd/tls/client/etcd-client.crt --key /etc/etcd/tls/client/etcd-client.key --endpoints=localhost:2379 snapshot save /var/lib/data/snapshot.db oc exec -it etcd-0 -n ${HOSTED_CLUSTER_NAMESPACE} -- env ETCDCTL_API=3 /usr/bin/etcdctl -w table snapshot status /var/lib/data/snapshot.db$ oc exec -it etcd-0 -n ${HOSTED_CLUSTER_NAMESPACE} -- env ETCDCTL_API=3 /usr/bin/etcdctl --cacert /etc/etcd/tls/client/etcd-client-ca.crt --cert /etc/etcd/tls/client/etcd-client.crt --key /etc/etcd/tls/client/etcd-client.key --endpoints=localhost:2379 snapshot save /var/lib/data/snapshot.db $ oc exec -it etcd-0 -n ${HOSTED_CLUSTER_NAMESPACE} -- env ETCDCTL_API=3 /usr/bin/etcdctl -w table snapshot status /var/lib/data/snapshot.dbCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次の例に示すように、S3 バケットなど、後で取得できる場所にスナップショットデータをコピーします。
注記次の例では、署名バージョン 2 を使用しています。署名バージョン 4 をサポートするリージョン (例: us-east-2 リージョン) にいる場合は、署名バージョン 4 を使用してください。それ以外の場合は、署名バージョン 2 を使用してスナップショットを S3 バケットにコピーすると、アップロードは失敗し、署名バージョン 2 は非推奨になります。
例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 後で新しいクラスターでスナップショットを復元できるようにする場合は、この例に示すように、ホストされたクラスターが参照する暗号化シークレットを保存します。
例
oc get hostedcluster $CLUSTER_NAME -o=jsonpath='{.spec.secretEncryption.aescbc}' {"activeKey":{"name":"CLUSTER_NAME-etcd-encryption-key"}} # Save this secret, or the key it contains so the etcd data can later be decrypted oc get secret ${CLUSTER_NAME}-etcd-encryption-key -o=jsonpath='{.data.key}'oc get hostedcluster $CLUSTER_NAME -o=jsonpath='{.spec.secretEncryption.aescbc}' {"activeKey":{"name":"CLUSTER_NAME-etcd-encryption-key"}} # Save this secret, or the key it contains so the etcd data can later be decrypted oc get secret ${CLUSTER_NAME}-etcd-encryption-key -o=jsonpath='{.data.key}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 
次のステップ
etcd スナップショットを復元します。
4.1.2. ホステッドクラスターでの etcd スナップショットの復元 リンクのコピーリンクがクリップボードにコピーされました!
ホステッドクラスターからの etcd のスナップショットがある場合は、それを復元できます。現在、クラスターの作成中にのみ etcd スナップショットを復元できます。
					etcd スナップショットを復元するには、create cluster --render コマンドからの出力を変更し、HostedCluster 仕様の etcd セクションで restoreSnapshotURL 値を定義します。
				
						hcp create コマンドの --render フラグはシークレットをレンダリングしません。シークレットをレンダリングするには、hcp create コマンドで --render フラグと --render-sensitive フラグの両方を使用する必要があります。
					
前提条件
ホステッドクラスターで etcd スナップショットを作成している。
手順
awsコマンドラインインターフェイス (CLI) で事前に署名された URL を作成し、認証情報を etcd デプロイメントに渡さずに S3 から etcd スナップショットをダウンロードできるようにします。ETCD_SNAPSHOT=${ETCD_SNAPSHOT:-"s3://${BUCKET_NAME}/${CLUSTER_NAME}-snapshot.db"} ETCD_SNAPSHOT_URL=$(aws s3 presign ${ETCD_SNAPSHOT})ETCD_SNAPSHOT=${ETCD_SNAPSHOT:-"s3://${BUCKET_NAME}/${CLUSTER_NAME}-snapshot.db"} ETCD_SNAPSHOT_URL=$(aws s3 presign ${ETCD_SNAPSHOT})Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の URL を参照するように
HostedCluster仕様を変更します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 
							
spec.secretEncryption.aescbc値から参照したシークレットに、前の手順で保存したものと同じ AES キーが含まれていることを確認します。 
4.2. AWS リージョン内のホストされたクラスターの障害復旧 リンクのコピーリンクがクリップボードにコピーされました!
ホストされたクラスターの障害復旧 (DR) が必要な状況では、ホストされたクラスターを AWS 内の同じリージョンに回復できます。たとえば、管理クラスターのアップグレードが失敗し、ホストされているクラスターが読み取り専用状態になっている場合、DR が必要です。
Hosted Control Plane は、テクノロジープレビュー機能としてのみ利用できます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
DR プロセスには、次の 3 つの主要な手順が含まれます。
- ソース管理クラスターでのホストされたクラスターのバックアップ
 - 宛先管理クラスターでのホステッドクラスターの復元
 - ホステッドクラスターのソース管理クラスターからの削除
 
プロセス中、ワークロードは引き続き実行されます。クラスター API は一定期間使用できない場合がありますが、ワーカーノードで実行されているサービスには影響しません。
					次の例に示すように、ソース管理クラスターと宛先管理クラスターの両方に --external-dns フラグを設定して、API サーバー URL を維持する必要があります。
				
例: 外部 DNS フラグ
--external-dns-provider=aws \ --external-dns-credentials=<AWS Credentials location> \ --external-dns-domain-filter=<DNS Base Domain>
--external-dns-provider=aws \
--external-dns-credentials=<AWS Credentials location> \
--external-dns-domain-filter=<DNS Base Domain>
					これにより、サーバー URL は https://api-sample-hosted.sample-hosted.aws.openshift.com で終わります。
				
					API サーバー URL を維持するために --external-dns フラグを含めない場合、ホストされたクラスターを移行することはできません。
				
4.2.1. 環境とコンテキストの例 リンクのコピーリンクがクリップボードにコピーされました!
復元するクラスターが 3 つあるシナリオを考えてみます。2 つは管理クラスターで、1 つはホストされたクラスターです。コントロールプレーンのみ、またはコントロールプレーンとノードのいずれかを復元できます。開始する前に、以下の情報が必要です。
- ソース MGMT namespace: ソース管理 namespace
 - ソース MGMT ClusterName: ソース管理クラスター名
 - 
							ソース MGMT Kubeconfig: ソース管理 
kubeconfigファイル - 
							宛先 MGMT Kubeconfig: 宛先管理 
kubeconfigファイル - 
							HC Kubeconfig: ホストされたクラスターの 
kubeconfigファイル - SSH 鍵ファイル: SSH 公開鍵
 - プルシークレット: リリースイメージにアクセスするためのプルシークレットファイル
 - AWS 認証情報
 - AWS リージョン
 - ベースドメイン: 外部 DNS として使用する DNS ベースドメイン
 - S3 バケット名: etcd バックアップをアップロードする予定の AWS リージョンのバケット
 
この情報は、次の環境変数の例に示されています。
環境変数の例
4.2.2. バックアップおよび復元プロセスの概要 リンクのコピーリンクがクリップボードにコピーされました!
バックアップと復元のプロセスは、以下のような仕組みとなっています。
管理クラスター 1 (ソース管理クラスターと見なすことができます) では、コントロールプレーンとワーカーが外部 DNS API を使用して対話します。外部 DNS API はアクセス可能で、管理クラスター間にロードバランサーが配置されています。
ホステッドクラスターのスナップショットを作成します。これには、etcd、コントロールプレーン、およびワーカーノードが含まれます。このプロセスの間、ワーカーノードは外部 DNS API にアクセスできなくても引き続きアクセスを試みます。また、ワークロードが実行され、コントロールプレーンがローカルマニフェストファイルに保存され、etcd が S3 バケットにバックアップされます。データプレーンはアクティブで、コントロールプレーンは一時停止しています。
管理クラスター 2 (宛先管理クラスターと見なすことができます) では、S3 バケットから etcd を復元し、ローカルマニフェストファイルからコントロールプレーンを復元します。このプロセスの間、外部 DNS API は停止し、ホステッドクラスター API にアクセスできなくなり、API を使用するワーカーはマニフェストファイルを更新できなくなりますが、ワークロードは引き続き実行されます。
外部 DNS API に再びアクセスできるようになり、ワーカーノードはそれを使用して管理クラスター 2 に移動します。外部 DNS API は、コントロールプレーンを参照するロードバランサーにアクセスできます。
管理クラスター 2 では、コントロールプレーンとワーカーノードが外部 DNS API を使用して対話します。リソースは、etcd の S3 バックアップを除いて、管理クラスター 1 から削除されます。ホステッドクラスターを管理クラスター 1 で再度設定しようとしても、機能しません。
ホストされたクラスターを手動でバックアップおよび復元するか、スクリプトを実行してプロセスを完了することができます。スクリプトの詳細については、「ホストされたクラスターをバックアップおよび復元するためのスクリプトの実行」を参照してください。
4.2.3. ホストされたクラスターのバックアップ リンクのコピーリンクがクリップボードにコピーされました!
ターゲット管理クラスターでホストされたクラスターを復元するには、最初にすべての関連データをバックアップする必要があります。
手順
以下のコマンドを入力して、configmap ファイルを作成し、ソース管理クラスターを宣言します。
oc create configmap mgmt-parent-cluster -n default --from-literal=from=${MGMT_CLUSTER_NAME}$ oc create configmap mgmt-parent-cluster -n default --from-literal=from=${MGMT_CLUSTER_NAME}Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを入力して、ホストされたクラスターとノードプールの調整をシャットダウンします。
PAUSED_UNTIL="true" oc patch -n ${HC_CLUSTER_NS} hostedclusters/${HC_CLUSTER_NAME} -p '{"spec":{"pausedUntil":"'${PAUSED_UNTIL}'"}}' --type=merge oc scale deployment -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --replicas=0 kube-apiserver openshift-apiserver openshift-oauth-apiserver control-plane-operator$ PAUSED_UNTIL="true" $ oc patch -n ${HC_CLUSTER_NS} hostedclusters/${HC_CLUSTER_NAME} -p '{"spec":{"pausedUntil":"'${PAUSED_UNTIL}'"}}' --type=merge $ oc scale deployment -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --replicas=0 kube-apiserver openshift-apiserver openshift-oauth-apiserver control-plane-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow PAUSED_UNTIL="true" oc patch -n ${HC_CLUSTER_NS} hostedclusters/${HC_CLUSTER_NAME} -p '{"spec":{"pausedUntil":"'${PAUSED_UNTIL}'"}}' --type=merge oc patch -n ${HC_CLUSTER_NS} nodepools/${NODEPOOLS} -p '{"spec":{"pausedUntil":"'${PAUSED_UNTIL}'"}}' --type=merge oc scale deployment -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --replicas=0 kube-apiserver openshift-apiserver openshift-oauth-apiserver control-plane-operator$ PAUSED_UNTIL="true" $ oc patch -n ${HC_CLUSTER_NS} hostedclusters/${HC_CLUSTER_NAME} -p '{"spec":{"pausedUntil":"'${PAUSED_UNTIL}'"}}' --type=merge $ oc patch -n ${HC_CLUSTER_NS} nodepools/${NODEPOOLS} -p '{"spec":{"pausedUntil":"'${PAUSED_UNTIL}'"}}' --type=merge $ oc scale deployment -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --replicas=0 kube-apiserver openshift-apiserver openshift-oauth-apiserver control-plane-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の bash スクリプトを実行して、etcd をバックアップし、データを S3 バケットにアップロードします。
ヒントこのスクリプトを関数でラップし、メイン関数から呼び出します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow etcd のバックアップの詳細は、「ホステッドクラスターでの etcd のバックアップと復元」を参照してください。
以下のコマンドを入力して、Kubernetes および OpenShift Container Platform オブジェクトをバックアップします。次のオブジェクトをバックアップする必要があります。
- 
									HostedCluster namespace の 
HostedClusterおよびNodePoolオブジェクト - 
									HostedCluster namespace の 
HostedClusterシークレット - 
									Hosted Control Plane namespace の 
HostedControlPlane - 
									Hosted Control Plane namespace の 
Cluster - 
									Hosted Control Plane namespace の 
AWSCluster、AWSMachineTemplate、およびAWSMachine - 
									Hosted Control Plane namespace の 
MachineDeployments、MachineSets、およびMachines Hosted Control Plane namespace の
ControlPlaneシークレットCopy to Clipboard Copied! Toggle word wrap Toggle overflow 
- 
									HostedCluster namespace の 
 次のコマンドを入力して、
ControlPlaneルートをクリーンアップします。oc delete routes -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --all$ oc delete routes -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --allCopy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドを入力すると、ExternalDNS Operator が Route53 エントリーを削除できるようになります。
次のスクリプトを実行して、Route53 エントリーがクリーンであることを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 
検証
すべての OpenShift Container Platform オブジェクトと S3 バケットをチェックし、すべてが想定どおりであることを確認します。
次のステップ
ホステッドクラスターを復元します。
4.2.4. ホステッドクラスターの復元 リンクのコピーリンクがクリップボードにコピーされました!
バックアップしたすべてのオブジェクトを収集し、宛先管理クラスターに復元します。
前提条件
ソース管理クラスターからデータをバックアップしている。
					宛先管理クラスターの kubeconfig ファイルが、KUBECONFIG 変数に設定されているとおりに、あるいは、スクリプトを使用する場合は MGMT2_KUBECONFIG 変数に設定されているとおりに配置されていることを確認します。export KUBECONFIG=<Kubeconfig FilePath> を使用するか、スクリプトを使用する場合は export KUBECONFIG=${MGMT2_KUBECONFIG} を使用します。
				
手順
以下のコマンドを入力して、新しい管理クラスターに、復元するクラスターの namespace が含まれていないことを確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを入力して、削除された namespace を再作成します。
Namespace creation oc new-project ${HC_CLUSTER_NS} oc new-project ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}# Namespace creation $ oc new-project ${HC_CLUSTER_NS} $ oc new-project ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、HC namespace のシークレットを復元します。
oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/secret-*$ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/secret-*Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを入力して、
HostedClusterコントロールプレーン namespace のオブジェクトを復元します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ノードとノードプールを復元して AWS インスタンスを再利用する場合は、次のコマンドを入力して、HC コントロールプレーン namespace のオブジェクトを復元します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の bash スクリプトを実行して、etcd データとホステッドクラスターを復元します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ノードとノードプールを復元して AWS インスタンスを再利用する場合は、次のコマンドを入力してノードプールを復元します。
oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/np-*$ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/np-*Copy to Clipboard Copied! Toggle word wrap Toggle overflow 
検証
ノードが完全に復元されたことを確認するには、次の関数を使用します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 
次のステップ
クラスターをシャットダウンして削除します。
4.2.5. ホステッドクラスターのソース管理クラスターからの削除 リンクのコピーリンクがクリップボードにコピーされました!
ホステッドクラスターをバックアップして宛先管理クラスターに復元した後、ソース管理クラスターのホステッドクラスターをシャットダウンして削除します。
前提条件
データをバックアップし、ソース管理クラスターに復元している。
					宛先管理クラスターの kubeconfig ファイルが、KUBECONFIG 変数に設定されているとおりに、あるいは、スクリプトを使用する場合は MGMT_KUBECONFIG 変数に設定されているとおりに配置されていることを確認します。export KUBECONFIG=<Kubeconfig FilePath> を使用するか、スクリプトを使用する場合は export KUBECONFIG=${MGMT_KUBECONFIG} を使用します。
				
手順
以下のコマンドを入力して、
deploymentおよびstatefulsetオブジェクトをスケーリングします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、
NodePoolオブジェクトを削除します。NODEPOOLS=$(oc get nodepools -n ${HC_CLUSTER_NS} -o=jsonpath='{.items[?(@.spec.clusterName=="'${HC_CLUSTER_NAME}'")].metadata.name}') if [[ ! -z "${NODEPOOLS}" ]];then oc patch -n "${HC_CLUSTER_NS}" nodepool ${NODEPOOLS} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]' oc delete np -n ${HC_CLUSTER_NS} ${NODEPOOLS} fiNODEPOOLS=$(oc get nodepools -n ${HC_CLUSTER_NS} -o=jsonpath='{.items[?(@.spec.clusterName=="'${HC_CLUSTER_NAME}'")].metadata.name}') if [[ ! -z "${NODEPOOLS}" ]];then oc patch -n "${HC_CLUSTER_NS}" nodepool ${NODEPOOLS} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]' oc delete np -n ${HC_CLUSTER_NS} ${NODEPOOLS} fiCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、
machineおよびmachinesetオブジェクトを削除します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、クラスターオブジェクトを削除します。
Cluster C_NAME=$(oc get cluster -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name) oc patch -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${C_NAME} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]' oc delete cluster.cluster.x-k8s.io -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --all# Cluster $ C_NAME=$(oc get cluster -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name) $ oc patch -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${C_NAME} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]' $ oc delete cluster.cluster.x-k8s.io -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --allCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、AWS マシン (Kubernetes オブジェクト) を削除します。実際の AWS マシンの削除を心配する必要はありません。クラウドインスタンスへの影響はありません。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、
HostedControlPlaneおよびControlPlaneHC namespace オブジェクトを削除します。Delete HCP and ControlPlane HC NS oc patch -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} hostedcontrolplane.hypershift.openshift.io ${HC_CLUSTER_NAME} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]' oc delete hostedcontrolplane.hypershift.openshift.io -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --all oc delete ns ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} || true# Delete HCP and ControlPlane HC NS $ oc patch -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} hostedcontrolplane.hypershift.openshift.io ${HC_CLUSTER_NAME} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]' $ oc delete hostedcontrolplane.hypershift.openshift.io -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --all $ oc delete ns ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} || trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを入力して、
HostedClusterおよび HC namespace オブジェクトを削除します。Delete HC and HC Namespace oc -n ${HC_CLUSTER_NS} patch hostedclusters ${HC_CLUSTER_NAME} -p '{"metadata":{"finalizers":null}}' --type merge || true oc delete hc -n ${HC_CLUSTER_NS} ${HC_CLUSTER_NAME} || true oc delete ns ${HC_CLUSTER_NS} || true# Delete HC and HC Namespace $ oc -n ${HC_CLUSTER_NS} patch hostedclusters ${HC_CLUSTER_NAME} -p '{"metadata":{"finalizers":null}}' --type merge || true $ oc delete hc -n ${HC_CLUSTER_NS} ${HC_CLUSTER_NAME} || true $ oc delete ns ${HC_CLUSTER_NS} || trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 
検証
すべてが機能することを確認するには、次のコマンドを入力します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 
次のステップ
ホステッドクラスター内の OVN Pod を削除して、新しい管理クラスターで実行される新しい OVN コントロールプレーンに接続できるようにします。
- 
							ホステッドクラスターの kubeconfig パスを使用して 
KUBECONFIG環境変数を読み込みます。 以下のコマンドを入力します。
oc delete pod -n openshift-ovn-kubernetes --all
$ oc delete pod -n openshift-ovn-kubernetes --allCopy to Clipboard Copied! Toggle word wrap Toggle overflow 
4.2.6. ホストされたクラスターをバックアップおよび復元するためのスクリプトの実行 リンクのコピーリンクがクリップボードにコピーされました!
ホストされたクラスターをバックアップし、AWS の同じリージョン内で復元するプロセスを迅速化するために、スクリプトを修正して実行できます。
手順
次のスクリプトの変数を独自の情報に置き換えます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - スクリプトをローカルファイルシステムに保存します。
 次のコマンドを入力して、スクリプトを実行します。
source <env_file>
source <env_file>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここの
env_fileは、スクリプトを保存したファイルの名前になります。移行スクリプトは、https://github.com/openshift/hypershift/blob/main/contrib/migration/migrate-hcp.sh のリポジトリーで管理されています。
        Legal Notice
        
          
            
          
        
       リンクのコピーリンクがクリップボードにコピーされました!
 
Copyright © 2025 Red Hat
OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).
Modified versions must remove all Red Hat trademarks.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.