5.3. OpenShift Virtualization での Hosted Control Plane の管理
OpenShift Virtualization にホステッドクラスターをデプロイした後、次の手順を実行してクラスターを管理できます。
5.3.1. ホステッドクラスターへのアクセス
ホステッドクラスターにアクセスするには、kubeconfig
ファイルと kubeadmin
認証情報をリソースから直接取得するか、hcp
コマンドラインインターフェイスを使用して kubeconfig
ファイルを生成します。
前提条件
リソースから kubeconfig
ファイルと認証情報を直接取得し、ホステッドクラスターにアクセスするには、ホステッドクラスターのアクセスシークレットを理解している必要があります。ホステッドクラスター (ホスティング) のリソースとアクセスシークレットは、ホステッドクラスターの namespace に格納されます。Hosted Control Plane は、Hosted Control Plane の namespace で実行されます。
シークレット名の形式は次のとおりです。
-
kubeconfig
シークレット:<hosted_cluster_namespace>-<name>-admin-kubeconfig
(clusters-hypershift-demo-admin-kubeconfig) -
kubeadmin
パスワードシークレット:<hosted_cluster_namespace>-<name>-kubeadmin-password
(clusters-hypershift-demo-kubeadmin-password)
kubeconfig
シークレットには Base64 でエンコードされた kubeconfig
フィールドが含まれており、これをデコードしてファイルに保存し、次のコマンドで使用できます。
$ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
kubeadmin
パスワードシークレットも Base64 でエンコードされます。これをデコードし、そのパスワードを使用して、ホステッドクラスターの API サーバーまたはコンソールにログインできます。
手順
hcp
CLI を使用してホステッドクラスターにアクセスしてkubeconfig
ファイルを生成するには、次の手順を実行します。次のコマンドを入力して、
kubeconfig
ファイルを生成します。$ hcp create kubeconfig --namespace <hosted_cluster_namespace> --name <hosted_cluster_name> > <hosted_cluster_name>.kubeconfig
kubeconfig
ファイルを保存した後、次のコマンド例を入力して、ホステッドクラスターにアクセスできます。$ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
5.3.2. OpenShift Virtualization での Hosted Control Plane のストレージの設定
詳細なストレージ設定を指定しなかった場合、KubeVirt 仮想マシン (VM) イメージ、KubeVirt Container Storage Interface (CSI) マッピング、および etcd ボリュームにデフォルトのストレージクラスが使用されます。
次の表に、ホステッドクラスターで永続ストレージをサポートするためにインフラストラクチャーが提供する必要がある機能を示します。
インフラストラクチャーの CSI プロバイダー | ホステッドクラスターの CSI プロバイダー | ホステッドクラスターの機能 | 注記 |
---|---|---|---|
任意の RWX |
|
基本: RWO | 推奨 |
任意の RWX | Red Hat OpenShift Data Foundation 外部モード | Red Hat OpenShift Data Foundation の機能セット | |
任意の RWX | Red Hat OpenShift Data Foundation 内部モード | Red Hat OpenShift Data Foundation の機能セット | 使用しないでください。 |
5.3.2.1. KubeVirt CSI ストレージクラスのマッピング
KubeVirt CSI は、ReadWriteMany
(RWX) アクセスが可能なインフラストラクチャーストレージクラスのマッピングをサポートします。クラスターの作成時に、インフラストラクチャーのストレージクラスをホストされるストレージクラスにマッピングできます。
手順
インフラストラクチャーのストレージクラスをホストされるストレージクラスにマッピングするには、次のコマンドを実行して
--infra-storage-class-mapping
引数を使用します。$ hcp create cluster kubevirt \ --name <hosted_cluster_name> \ 1 --node-pool-replicas <worker_node_count> \ 2 --pull-secret <path_to_pull_secret> \ 3 --memory <memory> \ 4 --cores <cpu> \ 5 --infra-storage-class-mapping=<infrastructure_storage_class>/<hosted_storage_class> \ 6
- 1
- ホステッドクラスターの名前を指定します (例:
example
)。 - 2
- ワーカー数を指定します (例:
2
)。 - 3
- プルシークレットへのパスを指定します (例:
/user/name/pullsecret
)。 - 4
- メモリーの値を指定します (例:
8Gi
)。 - 5
- CPU の値を指定します (例:
2
)。 - 6
<infrastructure_storage_class>
をインフラストラクチャーストレージクラス名に置き換え、<hosted_storage_class>
をホストされたクラスターストレージクラス名に置き換えます。hcp create cluster
コマンド内で--infra-storage-class-mapping
引数を複数回使用できます。
ホステッドクラスターを作成すると、インフラストラクチャーのストレージクラスがホステッドクラスター内に表示されます。これらのストレージクラスのいずれかを使用するホステッドクラスター内に永続ボリューム要求 PVC を作成すると、KubeVirt CSI はクラスターの作成時に設定したインフラストラクチャーストレージクラスマッピングを使用してそのボリュームをプロビジョニングします。
KubeVirt CSI は、RWX アクセスが可能なインフラストラクチャーストレージクラスのマッピングのみをサポートします。
次の表に、ボリュームモードとアクセスモードの機能が KubeVirt CSI ストレージクラスにどのようにマッピングされるかを示します。
インフラストラクチャーの CSI 機能 | ホステッドクラスターの CSI 機能 | 仮想マシンのライブ移行のサポート | 注記 |
---|---|---|---|
RWX: |
| サポート対象 |
|
RWO |
RWO | サポート対象外 | ライブマイグレーションのサポートが不足しているため、KubeVirt 仮想マシンをホストする基盤となるインフラストラクチャークラスターを更新する機能が影響を受けます。 |
RWO |
RWO | サポート対象外 |
ライブマイグレーションのサポートが不足しているため、KubeVirt 仮想マシンをホストする基盤となるインフラストラクチャークラスターを更新する機能が影響を受けます。インフラストラクチャー |
5.3.2.2. 単一の KubeVirt CSI ボリュームスナップショットクラスのマッピング
KubeVirt CSI を使用して、インフラストラクチャーのボリュームスナップショットクラスをホステッドクラスターに公開できます。
手順
ボリュームスナップショットクラスをホステッドクラスターにマッピングするには、ホステッドクラスターを作成するときに
--infra-volumesnapshot-class-mapping
引数を使用します。以下のコマンドを実行します。$ hcp create cluster kubevirt \ --name <hosted_cluster_name> \ 1 --node-pool-replicas <worker_node_count> \ 2 --pull-secret <path_to_pull_secret> \ 3 --memory <memory> \ 4 --cores <cpu> \ 5 --infra-storage-class-mapping=<infrastructure_storage_class>/<hosted_storage_class> \ 6 --infra-volumesnapshot-class-mapping=<infrastructure_volume_snapshot_class>/<hosted_volume_snapshot_class> 7
- 1
- ホステッドクラスターの名前を指定します (例:
example
)。 - 2
- ワーカー数を指定します (例:
2
)。 - 3
- プルシークレットへのパスを指定します (例:
/user/name/pullsecret
)。 - 4
- メモリーの値を指定します (例:
8Gi
)。 - 5
- CPU の値を指定します (例:
2
)。 - 6
<infrastructure_storage_class>
は、インフラストラクチャークラスターに存在するストレージクラスに置き換えます。<hosted_storage_class>
は、ホステッドクラスターに存在するストレージクラスに置き換えます。- 7
<infrastructure_volume_snapshot_class>
は、インフラストラクチャークラスターに存在するボリュームスナップショットクラスに置き換えます。<hosted_volume_snapshot_class>
は、ホステッドクラスターに存在するボリュームスナップショットクラスに置き換えます。
注記--infra-storage-class-mapping
および--infra-volumesnapshot-class-mapping
引数を使用しない場合、デフォルトのストレージクラスとボリュームスナップショットクラスを使用してホステッドクラスターが作成されます。したがって、インフラストラクチャークラスターでデフォルトのストレージクラスとボリュームスナップショットクラスを設定する必要があります。
5.3.2.3. 複数の KubeVirt CSI ボリュームスナップショットクラスのマッピング
複数のボリュームスナップショットクラスを特定のグループに割り当てることで、それらをホステッドクラスターにマッピングできます。インフラストラクチャーのストレージクラスとボリュームスナップショットクラスは、同じグループに属している場合にのみ相互に互換性があります。
手順
複数のボリュームスナップショットクラスをホステッドクラスターにマッピングするには、ホステッドクラスターを作成するときに
group
オプションを使用します。以下のコマンドを実行します。$ hcp create cluster kubevirt \ --name <hosted_cluster_name> \ 1 --node-pool-replicas <worker_node_count> \ 2 --pull-secret <path_to_pull_secret> \ 3 --memory <memory> \ 4 --cores <cpu> \ 5 --infra-storage-class-mapping=<infrastructure_storage_class>/<hosted_storage_class>,group=<group_name> \ 6 --infra-storage-class-mapping=<infrastructure_storage_class>/<hosted_storage_class>,group=<group_name> \ --infra-storage-class-mapping=<infrastructure_storage_class>/<hosted_storage_class>,group=<group_name> \ --infra-volumesnapshot-class-mapping=<infrastructure_volume_snapshot_class>/<hosted_volume_snapshot_class>,group=<group_name> \ 7 --infra-volumesnapshot-class-mapping=<infrastructure_volume_snapshot_class>/<hosted_volume_snapshot_class>,group=<group_name>
- 1
- ホステッドクラスターの名前を指定します (例:
example
)。 - 2
- ワーカー数を指定します (例:
2
)。 - 3
- プルシークレットへのパスを指定します (例:
/user/name/pullsecret
)。 - 4
- メモリーの値を指定します (例:
8Gi
)。 - 5
- CPU の値を指定します (例:
2
)。 - 6
<infrastructure_storage_class>
は、インフラストラクチャークラスターに存在するストレージクラスに置き換えます。<hosted_storage_class>
は、ホステッドクラスターに存在するストレージクラスに置き換えます。<group_name>
は、グループ名に置き換えます。たとえば、infra-storage-class-mygroup/hosted-storage-class-mygroup,group=mygroup
およびinfra-storage-class-mymap/hosted-storage-class-mymap,group=mymap
です。- 7
<infrastructure_volume_snapshot_class>
は、インフラストラクチャークラスターに存在するボリュームスナップショットクラスに置き換えます。<hosted_volume_snapshot_class>
は、ホステッドクラスターに存在するボリュームスナップショットクラスに置き換えます。たとえば、infra-vol-snap-mygroup/hosted-vol-snap-mygroup,group=mygroup
およびinfra-vol-snap-mymap/hosted-vol-snap-mymap,group=mymap
です。
5.3.2.4. KubeVirt 仮想マシンのルートボリュームの設定
クラスターの作成時に、--root-volume-storage-class
引数を使用して、KubeVirt 仮想マシンルートボリュームをホストするために使用するストレージクラスを設定できます。
手順
KubeVirt 仮想マシンのカスタムのストレージクラスとボリュームサイズを設定するには、次のコマンドを実行します。
$ hcp create cluster kubevirt \ --name <hosted_cluster_name> \ 1 --node-pool-replicas <worker_node_count> \ 2 --pull-secret <path_to_pull_secret> \ 3 --memory <memory> \ 4 --cores <cpu> \ 5 --root-volume-storage-class <root_volume_storage_class> \ 6 --root-volume-size <volume_size> 7
これにより、PVC 上でホストされる仮想マシンを使用してホステッドクラスターが作成されます。
5.3.2.5. KubeVirt 仮想マシンイメージキャッシュの有効化
KubeVirt 仮想マシンイメージキャッシュを使用すると、クラスターの起動時間とストレージ使用量の両方を最適化できます。KubeVirt 仮想マシンイメージキャッシュは、スマートクローニングと ReadWriteMany
アクセスモードが可能なストレージクラスの使用をサポートします。スマートクローン作成の詳細は、smart-cloning を使用したデータボリュームのクローン作成 を参照してください。
イメージのキャッシュは次のように機能します。
- VM イメージは、ホステッドクラスターに関連付けられた PVC にインポートされます。
- その PVC の一意のクローンは、クラスターにワーカーノードとして追加されるすべての KubeVirt VM に対して作成されます。
イメージキャッシュを使用すると、イメージのインポートが 1 つだけ必要になるため、VM の起動時間が短縮されます。ストレージクラスがコピーオンライトクローン作成をサポートしている場合、クラスター全体のストレージ使用量をさらに削減できます。
手順
イメージキャッシュを有効にするには、クラスターの作成時に、次のコマンドを実行して
--root-volume-cache-strategy=PVC
引数を使用します。$ hcp create cluster kubevirt \ --name <hosted_cluster_name> \ 1 --node-pool-replicas <worker_node_count> \ 2 --pull-secret <path_to_pull_secret> \ 3 --memory <memory> \ 4 --cores <cpu> \ 5 --root-volume-cache-strategy=PVC 6
5.3.2.6. KubeVirt CSI ストレージのセキュリティーと分離
KubeVirt Container Storage Interface (CSI) は、基盤となるインフラストラクチャークラスターのストレージ機能をホステッドクラスターに拡張します。CSI ドライバーは、インフラストラクチャーストレージクラスとホステッドクラスターへの分離されたセキュアなアクセスを実現するために、次のセキュリティー制約を使用します。
- ホステッドクラスターのストレージは、他のホステッドクラスターから分離されます。
- ホステッドクラスター内のワーカーノードは、インフラストラクチャークラスターに直接 API によってアクセスできません。ホステッドクラスターは、制御された KubeVirt CSI インターフェイスを通じてのみ、インフラストラクチャークラスター上にストレージをプロビジョニングできます。
- ホステッドクラスターは、KubeVirt CSI クラスターコントローラーにアクセスできません。そのため、ホステッドクラスターは、ホステッドクラスターに関連付けられていないインフラストラクチャークラスター上の任意のストレージボリュームにアクセスできません。KubeVirt CSI クラスターコントローラーは、Hosted Control Plane namespace の Pod で実行されます。
- KubeVirt CSI クラスターコントローラーのロールベースアクセス制御 (RBAC) により、永続ボリューム要求 (PVC) アクセスが Hosted Control Plane namespace だけに制限されます。したがって、KubeVirt CSI コンポーネントは他の namespace からストレージにアクセスできません。
5.3.2.7. etcd ストレージの設定
クラスターの作成時に、--etcd-storage-class
引数を使用して、etcd データをホストするために使用されるストレージクラスを設定できます。
手順
etcd のストレージクラスを設定するには、次のコマンドを実行します。
$ hcp create cluster kubevirt \ --name <hosted_cluster_name> \ 1 --node-pool-replicas <worker_node_count> \ 2 --pull-secret <path_to_pull_secret> \ 3 --memory <memory> \ 4 --cores <cpu> \ 5 --etcd-storage-class=<etcd_storage_class_name> 6
5.3.3. hcp CLI を使用して NVIDIA GPU デバイスをアタッチする
OpenShift Virtualization 上のホステッドクラスターの hcp
コマンドラインインターフェイス (CLI) を使用して、1 つ以上の NVIDIA グラフィックスプロセッシングユニット (GPU) デバイスをノードプールにアタッチできます。
NVIDIA GPU デバイスをノードプールにアタッチする機能は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
前提条件
- GPU デバイスが存在するノード上のリソースとして NVIDIA GPU デバイスを公開した。詳細は、NVIDIA GPU Operator with OpenShift Virtualization を参照してください。
- ノードプールに割り当てるために、NVIDIA GPU デバイスをノード上の 拡張リソース として公開した。
手順
次のコマンドを実行すると、クラスターの作成中に GPU デバイスをノードプールにアタッチできます。
$ hcp create cluster kubevirt \ --name <hosted_cluster_name> \1 --node-pool-replicas <worker_node_count> \2 --pull-secret <path_to_pull_secret> \3 --memory <memory> \4 --cores <cpu> \5 --host-device-name="<gpu_device_name>,count:<value>" 6
- 1
- ホステッドクラスターの名前を指定します (例:
example
)。 - 2
- ワーカー数を指定します (例:
3
)。 - 3
- プルシークレットへのパスを指定します (例:
/user/name/pullsecret
)。 - 4
- メモリーの値を指定します (例:
16Gi
)。 - 5
- CPU の値を指定します (例:
2
)。 - 6
- GPU デバイス名と数を指定します (例:
--host-device-name="nvidia-a100,count:2"
)。--host-device-name
引数は、インフラストラクチャーノードからの GPU デバイスの名前と、ノードプール内の各仮想マシンにアタッチする GPU デバイスの数を表すオプション数を取得します。デフォルトは1
です。たとえば、2 つの GPU デバイスを 3 つのノードプールレプリカにアタッチすると、ノードプール内の 3 つの仮想マシンすべてが 2 つの GPU デバイスにアタッチされます。
ヒント--host-device-name
引数を複数回使用して、タイプの異なる複数デバイスをアタッチできます。
5.3.4. NodePool リソースを使用して NVIDIA GPU デバイスをアタッチする
NodePool
リソースの nodepool.spec.platform.kubevirt.hostDevices
フィールドを設定することで、1 つ以上の NVIDIA グラフィックスプロセッシングユニット (GPU) デバイスをノードプールにアタッチできます。
NVIDIA GPU デバイスをノードプールにアタッチする機能は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
手順
1 つ以上の GPU デバイスをノードプールにアタッチします。
1 つの GPU デバイスをアタッチするには、次の設定例を使用して
NodePool
リソースを設定します。apiVersion: hypershift.openshift.io/v1beta1 kind: NodePool metadata: name: <hosted_cluster_name> 1 namespace: <hosted_cluster_namespace> 2 spec: arch: amd64 clusterName: <hosted_cluster_name> management: autoRepair: false upgradeType: Replace nodeDrainTimeout: 0s nodeVolumeDetachTimeout: 0s platform: kubevirt: attachDefaultNetwork: true compute: cores: <cpu> 3 memory: <memory> 4 hostDevices: 5 - count: <count> 6 deviceName: <gpu_device_name> 7 networkInterfaceMultiqueue: Enable rootVolume: persistent: size: 32Gi type: Persistent type: KubeVirt replicas: <worker_node_count> 8
- 1
- ホステッドクラスターの名前を指定します (例:
example
)。 - 2
- ホステッドクラスターの namespace の名前を指定します (例:
clusters
)。 - 3
- CPU の値を指定します (例:
2
)。 - 4
- メモリーの値を指定します (例:
16Gi
)。 - 5
hostDevices
フィールドは、ノードプールにアタッチできる各種 GPU デバイスのリストを定義します。- 6
- ノードプール内の各仮想マシンにアタッチする GPU デバイスの数を指定します。たとえば、2 つの GPU デバイスを 3 つのノードプールレプリカにアタッチすると、ノードプール内の 3 つの仮想マシンすべてが 2 つの GPU デバイスにアタッチされます。デフォルトは
1
です。 - 7
- GPU デバイス名を指定します (例:
nvidia-a100
)。 - 8
- ワーカー数を指定します (例:
3
)。
複数の GPU デバイスをアタッチするには、次の設定例を使用して
NodePool
リソースを設定します。apiVersion: hypershift.openshift.io/v1beta1 kind: NodePool metadata: name: <hosted_cluster_name> namespace: <hosted_cluster_namespace> spec: arch: amd64 clusterName: <hosted_cluster_name> management: autoRepair: false upgradeType: Replace nodeDrainTimeout: 0s nodeVolumeDetachTimeout: 0s platform: kubevirt: attachDefaultNetwork: true compute: cores: <cpu> memory: <memory> hostDevices: - count: <count> deviceName: <gpu_device_name> - count: <count> deviceName: <gpu_device_name> - count: <count> deviceName: <gpu_device_name> - count: <count> deviceName: <gpu_device_name> networkInterfaceMultiqueue: Enable rootVolume: persistent: size: 32Gi type: Persistent type: KubeVirt replicas: <worker_node_count>