Red Hatの小島です。
Amazon Web Services (以下、AWS)では非仮想化環境や独自のハイパーバイザーでのアプリケーション実行を希望するユーザーに対して、東京と大阪リージョンを含む様々なリージョンでのAmazon EC2上のベアメタルインスタンスの実行をサポートしています。こうしたベアメタルインスタンスのサポートを利用して、Red Hat OpenShift Service on AWS (ROSA) では、ROSA with Hosted Control Plane (以下、ROSA HCP) 上でのOpenShift Virtualizationを利用した仮想化環境の実行を、ROSA HCP ver.4.16からサポートするようになりました。ROSAでのOpenShift Virtualizationを利用すると、ユーザーは次のようなメリットを享受できるようになります。
- 移行ツールを利用した、既存VMware環境上の仮想マシンのAWSへの迅速な移行
- オンプレミスとAWSのハイブリッドクラウドに対して、OpenShiftを利用したアプリケーション開発と運用の統一
- AWSでの、OpenShift Virtualizationに含まれる無制限のRHELサブスクリプションの利用
- 従量課金制のAWSというクラウドの特徴を利用した、OpenShift Virtualizationの本格導入前検証やインフラ環境構築/拡張の簡単化
これらのメリットなどを記載したOpenShift Virtualization on ROSAに関するブログが、AWSのWebページでも公開されていますのでご参照ください。
本記事では、ROSA HCPでのOpenShift Virtualizationの利用方法とそのポイントをご紹介します。
- 事前準備
- ROSA HCPクラスターでのOpenShift Virtualizationのインストールと利用
- Amazon FSx for NetApp ONTAPのファイルシステム作成
- (補足) Multi-AZ構成時のAmazon FSx for NetApp ONTAPのファイルシステム作成
- ROSA HCPクラスターへのNetApp Trident CSIドライバのインストールと設定
- 仮想マシンの作成
- Red Hat Subscription Manager (RHSM)に自動登録するためのアクティベーションキーの作成と利用
- カスタムテンプレートの作成
- クリーンアップ
- まとめ
事前準備
ROSA HCPでのOpenShift Virtualizationを利用するには、次のリソースが必要になります。
- ROSA HCPクラスター (ver. 4.16以降)
- クラスター作成に必要となるAWSアカウントやRed Hatアカウントなどの各種リソースを含みます。
- AWSのAmazon FSx for NetApp ONTAPを作成および利用する権限
- この共有ストレージは、後述するOpenShift Virtualizationでのライブマイグレーション用途として利用します。
ROSA HCPクラスターの作成方法については、下記のコンテンツをご参照ください。
ROSA HCPクラスターでのOpenShift Virtualizationのインストールと利用
ROSA HCPクラスターでのOpenShift Virtualizationは、通常のSelf-ManagedのOpenShiftと同じような方法でインストールと利用ができるようになっています。ただし、仮想マシンを実行するためにはベアメタルインスタンスが必要なので、ROSA HCPクラスターを作るとき、または、(ユーザーアプリケーションの実行ノードとなる)ワーカーノードを追加するときにインスタンスタイプをベアメタルタイプに指定する必要があります。ROSA HCPで利用可能なインスタンスタイプは下記をご参照ください。metalという拡張子が付いている名前のインスタンスタイプがベアメタルとなります。
また、AWSリージョンごとに利用できるAmazon EC2のインスタンスタイプは下記をご参照ください。
ROSA HCPクラスターにワーカーノードを追加/削除する方法については、下記のコンテンツをご参照ください。なお、ベアメタルインスタンスを追加する場合、大体30分ほどでワーカーノードの追加が完了します。
ROSA HCPクラスターにベアメタルインスタンスが追加されると、ROSA HCPクラスターのOpenShiftコンソールにcluster-adminなどの管理者アカウントでログインして下記のような画面で確認できます。この構成ではデフォルトのワーカーノード(m5.xlarge)2台に加えて、ベアメタルのワーカーノード(c5n.metal)を2台追加しています。ROSA HCPクラスターは、ワーカーノードに利用されるvCPU数が増えるほど利用料金が増えるため、最安料金で試そうとなると2024年10月時点ではm5zn.metal (48 vCPU, 192 GiB)をワーカーノードとして利用することになりますが、本記事ではAWSの東京/大阪リージョンでも利用可能なc5n.metal (72 vCPU, 192 GiB) を利用しています。
ベアメタルインスタンスのワーカーノードを追加したら、あとはSelf-Managed OpenShiftと同じ方法でOpenShift Virtualizationが利用できます。OpenShiftコンソールのOperator HubからOpenShift VirtualizationのOperatorをデフォルトのパラメーターをそのまま利用してインストールします。
OpenShift VirtualizationのOperatorからHyperConvergedインスタンスを作成します。これも全てデフォルトのパラメーターのままで「作成」をクリックして、kubevirt-hyperconvergedという名前のHyperConvergedインスタンスをopenshift-cnvプロジェクトに作成します。
数分待つとopenshift-cnvプロジェクトにOpenShift Virtualization関連のPodが実行されて、OpenShiftコンソールに「Virtualization」という追加されたメニューから仮想マシンを作成できるようになります。「Virtualization」メニューの表示には、OpenShiftのWebコンソールを再読み込みする必要があります。ここで表示されているテンプレートのカタログから、Red Hat Enterprise Linux (RHEL) などの仮想マシンを作成できます。
Amazon FSx for NetApp ONTAPのファイルシステム作成
このまま仮想マシンを作成してもいいのですが、ROSAのデフォルトのストレージクラスとして利用されるAmazon EBSのgp3ボリュームでは複数のEC2インスタンスからの共有ストレージとして利用不可であり、またAmazon EFSは共有ファイルシステムとして利用できますが、OpenShift Virtualizationの仮想マシンの共有ストレージとして利用するために必要となる共有ブロックストレージとしての利用ができなくなっています。そのため、ベアメタルインスタンス間の仮想マシンのライブマイグレーションが利用できません。
そこで、同じくAWSがサポートしている、共有ブロックストレージとして利用可能なAmazon FSx for NetApp ONTAPの共有ストレージを作成して利用します。ここでは、Single AZに作成したROSA HCPクラスターからAmazon FSx for NetApp ONTAPの共有ストレージを利用することを前提とします。
※ 本記事では以下の2つのブログを参考にしています。
AWSのAmazon FSxコンソールにログインして、ROSA HCPクラスターを作成したリージョンと同じリージョンに移動します。最初はファイルシステムが作成されていない状態なので、「ファイルシステムを作成」をクリックして作成していきます。
ファイルシステムのオプションから「Amazon FSx for NetApp ONTAP」を選択して「次へ」をクリックします。
続いて「スタンダード作成」をクリックして、以下のようにファイルシステムの詳細情報を入力します。
- ファイルシステムの詳細
- デプロイタイプ: シングルAZ 2
- SSDストレージ容量: 1024 GiB (最小値を指定)
- 残りのパラメーターはデフォルト値を利用
- ネットワークとセキュリティ (これらの情報は、Amazon EC2のコンソールから確認可能)
- VPC: 「ROSA HCPクラスターを作成したVPC」を選択
- VPCセキュリティグループ: 「ROSA HCPクラスターのワーカーノードが利用しているセキュリティグループ」を選択
- サブネット: 「ROSA HCPクラスターのワーカーノードが利用しているサブネット」を選択
- デフォルトのストレージ仮想マシン設定
- ストレージ仮想マシン名: svm1 (任意の名前を指定可能)
- SVM管理パスワード: 「パスワードを指定」を選択して、任意のパスワードを指定
- 残りのパラメーターはデフォルト値を利用
これら以外のパラメーターはデフォルト値のままにしておいて「次へ」をクリックして、最後に「ファイルシステムを作成」をクリックします。
すると、大体10分ほどでファイルシステムの作成が完了します。
(補足) Multi-AZ構成時のAmazon FSx for NetApp ONTAPのファイルシステム作成
前述した手順では、ROSA HCPクラスターとAmazon FSx for NetApp ONTAPのファイルシステムの両方ともSingle-AZ構成であることを想定しています。これを両方ともMulti-AZ構成にする場合、Single-AZ構成時のAmazon FSx for NetApp ONTAPのファイルシステム作成手順に、「ファイルシステムの詳細」の「デプロイタイプ: マルチAZ 2」への変更に加えて、下記の変更を適用します。
- ネットワークとセキュリティ (これらの情報は、Amazon EC2とAmazon VPCのコンソールから確認可能)
- VPC: 「ROSA HCPクラスターを作成したVPC」を選択
- VPCセキュリティグループ: 「ROSA HCPクラスターのワーカーノードが利用しているセキュリティグループ」を選択
- Multi-AZ構成の各ワーカーノードは、同じセキュリティグループを利用しています。
- 推奨サブネット: 「ワーカーノードが利用しているサブネット」を選択
- スタンバイサブネット: 「ワーカーノードが利用しているサブネット」を選択
- Multi-AZ構成のワーカーノードは、合計3つのプライベートサブネットを利用しているので、そのうち2つのサブネットを「推奨サブネット」「スタンバイサブネット」として選択します。
- VPCルートテーブル: ワーカーノードが利用しているサブネットに紐付けられた3つのルートテーブルを全て選択
- このサブネットは、Multi-AZ構成のワーカーノードが利用している3つのプライベートサブネットです。
- 残りのパラメーターはデフォルト値を利用
あとは、Single-AZ構成の時と同じ手順でファイルシステムを作成できます。
ROSA HCPクラスターへのNetApp Trident CSIドライバのインストールと設定
ここで作成したファイルシステムをROSA HCPクラスターから利用するために、Trident CSIドライバをインストールします。インストールにはROSA HCPクラスターのOpenShiftコンソールから利用できるWeb Terminalを、ROSA HCPクラスターの管理者アカウントで利用します。Web Terminalのインストールと利用方法については、下記のコンテンツをご参照ください。
Web Terminalが提供するコンソールを開いて、Trident CSIドライバのインストール先となるtridentプロジェクトを作成します。
oc new-project trident
次にTrident CSIドライバをGitリポジトリからダウンロードして、内容を展開します。ここでダウンロードしているドライバは、2024年10月時点での最新バージョン(v24.06.1)のものです。
curl -L -o trident.tar.gz https://github.com/NetApp/trident/releases/download/v24.06.1/trident-installer-24.06.1.tar.gz tar xf trident.tar.gz
最後にhelmコマンドで、tridentプロジェクトにTrident CSIドライバをインストールします。STATUSが「deployed」になれば、インストールが完了しています。CSIドライバのインストール状態については、helm status tridentコマンドやhelm get all tridentコマンドでも確認できます。
cd trident-installer/helm/ helm install trident -n trident trident-operator-100.2406.1.tgz ...<snip>... NAME: trident LAST DEPLOYED: Tue Oct 22 02:40:41 2024 NAMESPACE: trident STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: Thank you for installing trident-operator, which will deploy and manage NetApp's Trident CSI storage provisioner for Kubernetes. ...<snip>... To learn more about the release, try: $ helm status trident $ helm get all trident
これらのコマンドをOpenShiftのWeb Terminalで実行した場合の画像が下記になります。
Trident CSIドライバのインストールが完了すると、Trident Operatorによって自動的にtrident-node-linuxという接頭辞が付いたPodがワーカーノードの台数分だけ作成されます。ワーカーノードを追加/削除すると、それに応じてtrident-node-linuxPodが自動追加/自動削除されます。下記の画像は、ROSA HCPクラスターのワーカーノード3台構成に、Trident CSIドライバをインストールした時のtridentプロジェクトのPodの状態を表示したものです。
(補足) OpenShiftのOperatorHubを利用したNetApp Trident CSIドライバのインストール
OpenShiftのOperatorHubにもTrident CSIドライバをインストールするためのOperatorのカタログがありますので、helmコマンドでなく、OperatorHubのカタログを利用してTrident CSIドライバをインストールすることもできます。
OperatorHubのカタログから、「trident」を入力して「Astra Trident」Operatorを選択して、「インストール」をクリックします。
Astra Trident Operatorのインストール画面では、「インストール済みのnamespace」で「trident」プロジェクトを選択します。「trident」プロジェクトを作成していない場合は、「プロジェクトの作成」から「trident」プロジェクトを作成してください。そして「インストール」をクリックしてAstra Trident Operatorをインストールします。
Astra Trident Operatorのインストール完了後に、「Trident Orchestrator」インスタンスを作成します。下記の画面の「インスタンスの作成」をクリックして、あとはデフォルトのままで「作成」をクリックします。
「Trident Orchestrator」インスタンスの作成が完了すると、「trident」プロジェクトに前述したtrident-node-linuxPodが作成されていることを確認できます。
ストレージ仮想マシン(SVM)管理ユーザーとパスワードをROSA HCPクラスターに保存するためのシークレット作成
Amazon FSxのファイルシステムを作成するときに指定したSVM管理パスワードを、ROSA HCPクラスターから利用するためのシークレットbackend-fsx-ontap-nas-secretをtridentプロジェクトに作成します。OpenShiftのコンソールの右上にある「+」アイコンをクリックして、下記のYAMLファイルを入力して「作成」をクリックします。
apiVersion: v1 kind: Secret metadata: name: backend-fsx-ontap-nas-secret namespace: trident type: Opaque stringData: username: vsadmin password: <SVM管理パスワードを指定>
Amazon FSx for NetApp ONTAPのファイルシステムをTrident CSIのバックエンドとして設定
Amazon FSxのコンソールから、作成したSVMの「管理IPアドレス」と「NFS IPアドレス」「名前」を確認します。下記の画像では「10.0.0.124」と「svm1」となります。
確認したIPアドレスをもとに、バックエンド設定用のyamlファイルをOpenShiftのコンソールから入力して作成します。下記の「managementLIF」「dataLIF」「svm」については、それぞれご自身が作成したSVMの「管理IPアドレス」「NFS IPアドレス」「SVMの名前」に置き換えて下さい。
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
name: backend-fsx-ontap-nas
namespace: trident
spec:
version: 1
backendName: fsx-ontap
storageDriverName: ontap-nas
managementLIF: 10.0.0.124 # SVMの管理IPアドレス
dataLIF: 10.0.0.124 # SVMのNFS IPアドレス
svm: svm1 # SVMの名前
credentials:
name: backend-fsx-ontap-nas-secret
これでバックエンドとしての設定が完了です。次のコマンドを実行して、「PHASE: Bound」「STATUS: Success」となっていればバックエンド設定が無事に完了していることを確認できます。
oc get tbc -n trident NAME BACKEND NAME BACKEND UUID PHASE STATUS backend-fsx-ontap-nas fsx-ontap 53c2b404-5c7c-4c86-a649-a5816f6334d5 Bound Success
Amazon FSx for NetApp ONTAPのファイルシステムを利用したストレージクラスの作成
バックエンドの設定が完了したあとに、コンテナの永続ボリュームとして利用するためのストレージクラスを作成します。OpenShiftのコンソールから「StorageClasses」メニューを選択して、trident-csiという名前のストレージクラスを作成します。「回収ポリシー」と「ボリュームバインディングモード」は何を選択してもいいですが、この例では「保持」と「即時」を選択しています。
「プロビジョナー」は「csi.trident.netapp.io」を選択して、追加パラメーターとして「backendType: ontap-nas」を入力します。この「ontap-nas」はバックエンド設定時に指定した「storageDriverName」の名前となります。そして、「作成」をクリックしてストレージクラスを作成します。
また、仮想マシンのテンプレートカタログから仮想マシンを作成する際に簡単に利用できるようにするために、ここで作成したストレージクラスをデフォルトのストレージクラスに変更※します。ROSA HCPクラスターのデフォルトのストレージクラスはAmazon EBSのgp3ボリュームを利用するように自動設定されているので、このgp3-csiストレージクラスを選択してYAMLファイルを以下のように修正して保存することで、gp3-csiストレージクラスをデフォルトから外すことができます。
※ 仮想マシンを作成する際に、YAMLファイルからストレージクラスを指定することもできるので、ストレージクラスのデフォルト化は必須ではありません。
storageclass.kubernetes.io/is-default-class: 'true' -> storageclass.kubernetes.io/is-default-class: 'false'
そして、trident-csiストレージクラスをデフォルトにするために、YAMLファイルを以下のように修正して保存します。
annotations.storageclass.kubernetes.io/is-default-class: 'true' をYAMLファイルに追加
これでtrident-csiストレージクラスをデフォルトに設定することができました。
ここまで紹介しましたNetApp TridentをOpenShiftから利用する情報の詳細については、NetAppのドキュメントもご参照ください。
また、Amazon FSx for NetApp ONTAPを利用していてNetApp Tridentについて問い合わせをしたい場合、AWSのサポートケースを利用できます。サポートケースを作る際に、「Trident」カテゴリーを選択してください。必要に応じて、AWSサポートチームからNetApp社にエスカレーションされる仕組みになっています。
Amazon FSx for NetApp ONTAPを利用するためのインバウンドルールの追加
ROSA HCPクラスターのワーカーノードからAmazon FSx for NetApp ONTAPのファイルシステムを利用するためのインバウンドルールを、ワーカーノードが利用しているAmazon EC2のセキュリティグループに追加する必要があります。ROSA HCPクラスター作成時に指定したワーカーノードの「Machine CIDR」(下記の画像ではデフォルトの10.0.0.0/16を指定)からのアクセスを許可しないと、ファイルシステムが利用できないようになっています。下記のAWSドキュメントにあるインバウンドルールを参照しながら、Amazon EC2のコンソールまたはAWS CLIを利用して追加していきます。
セキュリティグループのインバウンドルールを追加すると、下記のような画像になります。この変更を保存します。
仮想マシンの作成
ここまでくれば、あとはSelf-Managed OpenShiftと同様に仮想マシンを作成したり、ライブマイグレーションしたりすることができます。ROSA HCPクラスターにローカルユーザー(下記の画像ではtestuser20)で再ログインして、適当なプロジェクト(下記の画像ではtest-project20)を作成したあとに、仮想マシンのテンプレートカタログからRHEL9の仮想マシンを作成してみます。「Red Hat Enterprise Linux 9 VM」をメニューから選択して、パラメーターはデフォルトのままで「Quick create VirtualMachine」をクリックして作成します。
OpenShift Virtualizationのインストール時に自動作成されたopenshift-virtualization-os-imagesプロジェクトにある、PVCのゴールデンイメージからデータをコピーした後に、RHEL9の仮想マシンが実行されて「Console」タブからVNCコンソールにアクセスできます。また、画面右上にある「Actions」から「Migrate」をクリックすることで、ベアメタルインスタンス間でのライブマイグレーションも数秒ほどで実行できます。
Red Hatが提供するゴールデンイメージの詳細については、下記をご参照ください。
Red Hat Subscription Manager (RHSM)に自動登録するためのアクティベーションキーの作成と利用
ROSA HCPで利用可能なOpenShift Virtualizationには、RHELの仮想マシンを無制限に実行できる権限が付与されます。デフォルトのRHELのテンプレートだと、Red Hat CDNのRHELリポジトリを利用したい場合、RHEL仮想マシン作成後にsubscription-managerコマンドでRHSMにシステム登録をする必要があります。このシステム登録には、ROSA HCPクラスター作成時に利用したRed Hatアカウントを利用してください。また、RHSMを利用するにいたって、ROSA HCPクラスターのプライベート化などによる送信トラフィック制限がある場合、次のホスト名とポートを許可してください。
- subscription.rhn.redhat.com:443 [https]
- subscription.rhsm.redhat.com:443 [https]
- cdn.redhat.com:443 [https]
- *.akamaiedge.net:443 [https]
- *.akamaitechnologies.com:443 [https]
RHEL仮想マシン作成後のRHSMへのシステム登録を自動化することもできます。この時、RHELシステムを登録するためのアクティベーションキーを、Red Hat Hybrid Cloud Consoleのコンソールから作成して利用することになります。
最初に、ROSA HCPクラスター作成時に利用したRed Hatアカウントで下記のURLにアクセスします。
https://console.redhat.com/insights/connector/activation-keys
すると次のような画面が表示されすので、ここからアクティベーションキーを作成します。この時表示されるRed Hatアカウントの「Organization ID」もメモしておいて下さい。「Create activation key」をクリックします。
アクティベーションキー作成画面に移りますので、任意の名前(下記画像では「activation-key01」)、Select Workloadでは「Extended support releases」とRHELのバージョンとなる「9.4」を選択します。これによって、アクティベーションキーを利用したRHELシステム登録後に、RHEL9のマイナーリリースの延長サポートであるExtended Update Support (EUS)のリポジトリを自動的に使えるようになります。ここで「Latest release」を選択した場合、RHELの最新マイナーリリースのリポジトリだけを使えるようになります。なお、アクティベーションキーでRHELシステムを登録した後も、RHELリポジトリの参照設定は自由に変更できます。
Roleは「RHEL Server」、SLAとUsageは適宜選択します。下記画像の例ではROSAのサポートレベルであるPremium(24時間365日サポート)に沿って「Premium」と「Production」を選択しています。これらの情報を確認した後に「Create」ボタンを押してアクティベーションキー「activation-key01」を作成します。
アクティベーションキーには、複数のRHELのメジャーリリースのリポジトリを紐づけることもできます。「Add repositories」をクリックしてRHEL8のEUSリポジトリを追加できます。これによって、このアクティベーションキーを利用してRHEL8とRHEL9のシステムを登録すると、RHEL8とRHEL9の最新マイナーリリースのリポジトリとEUSリポジトリの両方が最初から利用できるようになります。
作成したアクティベーションキーをテンプレートから利用するために、ROSA HCPクラスターの管理者アカウントでOpenShiftコンソールにログインして、「Virtualization」→「Overview」→「Settings」からアクティベーションキーの名前とOrganization IDを入力して「Apply」をクリックします。これによって、RHEL仮想マシンを作成するためのテンプレートから仮想マシン作成時に、自動的にアクティベーションキーによるシステム登録とリポジトリ有効化が実行されます。
実際に「Red Hat Enterprise Linux 9 VM」テンプレートからRHEL9仮想マシンを作成すると、cloud-initのポストスクリプトによるRHSMへの自動登録が実行されて、事前に設定したRHEL9とRHEL9のEUSリポジトリを最初から参照して、パッケージのインストール/アップデート/削除ができるようになっていることを確認できます。
カスタムテンプレートの作成
前述した手順で作成したアクティベーションキーを、特定のテンプレートだけに利用させるようなカスタムテンプレートを作成することもできます。カスタムテンプレート作成には、OpenShift Virtualization Operatorによって元々用意されているテンプレートをベースにします。RHEL9仮想マシンを作成するテンプレートだと、rhel9-server-smallという名前のテンプレートがopenshiftプロジェクトに用意されているので、このテンプレートのYAMLファイルを次のコマンドで表示します。
oc get template rhel9-server-small -n openshift -o yaml
apiVersion: template.openshift.io/v1
kind: Template
metadata:
annotations:
defaults.template.kubevirt.io/disk: rootdisk
description: Template for Red Hat Enterprise Linux 9 VM or newer. A PVC with the
RHEL disk image must be available.
...<snip>...
表示されたYAMLファイルの情報をコピーして、「Templates」メニューから「Create Template」ボタンを作成することで表示されるテキストボックスに貼り付けます。この時、下記の修正を適用して「作成」をクリックしてカスタムテンプレートを作成します。
- openshift.io/display-name: Subscribed Red Hat Enterprise Linux 9 VM に修正
- template.kubevirt.io/type: vm に修正
- name: subscribed-rhel9-server-small に修正
- namespace: test-project20 に修正
- vm.kubevirt.io/template: subscribed-rhel9-server-small に修正
- cloudInitNoCloud.userData の箇所に、rh_subscriptionの情報を追加
これらの修正をピックアップしたYAMLファイルは以下のようになります。
apiVersion: template.openshift.io/v1
kind: Template
metadata:
annotations:
...<snip>...
openshift.io/display-name: Subscribed Red Hat Enterprise Linux 9 VM
...<snip>...
template.kubevirt.io/type: vm
...<snip>...
name: subscribed-rhel9-server-small
namespace: test-project20
...<snip>...
vm.kubevirt.io/template: subscribed-rhel9-server-small
...<snip>...
- cloudInitNoCloud:
userData: |-
#cloud-config
user: cloud-user
password: ${CLOUD_USER_PASSWORD}
chpasswd: { expire: False }
rh_subscription:
activation-key: activation-key01 # アクティベーションキーの名前
org: <Red HatアカウントのOrganization IDを指定>
name: cloudinitdisk
...<snip>...
そして「作成」ボタンをクリックして、カスタムテンプレートをtest-project20プロジェクトに作成します。作成後は「Subscribed Red Hat Enterprise Linux 9 VM」という名前のテンプレートが利用できるようになっています。このカスタムテンプレートからRHEL9仮想マシンを作成すると、RHSMへの自動登録が実行されます。
OpenShift Virtualizationについての他の操作を試してみたい場合、下記の連載記事の第4回や第5回も併せてご参照ください。
rheb.hatenablog.com rheb.hatenablog.com
クリーンアップ
ROSA HCPでのOpenShift Virtualization環境を消去したい場合、ROSA HCPクラスターの削除とAmazon FSx for NetApp ONTAPのファイルシステム削除を実行してください。ROSA HCPクラスターの削除は、rosa delete clusterコマンドなどで実行できます。下記はrosa-hcp-01という名前のROSA HCPクラスターを削除するコマンドの例です。
rosa delete cluster -c rosa-hcp-01 --yes
ROSA HCPクラスターの削除については、下記のWebページにある「ROSA HCPクラスターの削除」の項目もご参照ください。
まとめ
このように、ROSA HCPクラスターではOpenShift Virtualizationを簡単に実行して、従量課金制で試してみることができます。OpenShift Virtualizationを試してみる際に、検証用マシンなどを用意するハードルが高い場合は、ぜひROSA HCPクラスターでのご利用をご検討ください。
