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 ファイルを生成するには、次の手順を実行します。

    1. 次のコマンドを入力して、kubeconfig ファイルを生成します。

      $ hcp create kubeconfig --namespace <hosted_cluster_namespace> --name <hosted_cluster_name> > <hosted_cluster_name>.kubeconfig
    2. 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 ボリュームにデフォルトのストレージクラスが使用されます。

次の表に、ホステッドクラスターで永続ストレージをサポートするためにインフラストラクチャーが提供する必要がある機能を示します。

表5.1 ホステッドクラスターの永続ストレージモード
インフラストラクチャーの CSI プロバイダーホステッドクラスターの CSI プロバイダーホステッドクラスターの機能注記

任意の RWX Block CSI プロバイダー

kubevirt-csi

基本: RWO Block および File、RWX Block および Snapshot

推奨

任意の RWX Block CSI プロバイダー

Red Hat OpenShift Data Foundation 外部モード

Red Hat OpenShift Data Foundation の機能セット

 

任意の RWX Block CSI プロバイダー

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 ストレージクラスにどのようにマッピングされるかを示します。

表5.2 KubeVirt CSI ストレージクラスとアクセスモードおよびボリュームモードのマッピング
インフラストラクチャーの CSI 機能ホステッドクラスターの CSI 機能仮想マシンのライブ移行のサポート注記

RWX: Block または Filesystem

ReadWriteOnce (RWO) Block または Filesystem RWX Block のみ

サポート対象

Filesystem ボリュームモードでは、ホストされた Block モードのパフォーマンスが低下するため、Block モードを使用してください。RWX Block ボリュームモードは、ホステッドクラスターが OpenShift Container Platform 4.16 以降の場合にのみサポートされます。

RWO Block ストレージ

RWO Block ストレージまたは Filesystem

サポート対象外

ライブマイグレーションのサポートが不足しているため、KubeVirt 仮想マシンをホストする基盤となるインフラストラクチャークラスターを更新する機能が影響を受けます。

RWO FileSystem

RWO Block または Filesystem

サポート対象外

ライブマイグレーションのサポートが不足しているため、KubeVirt 仮想マシンをホストする基盤となるインフラストラクチャークラスターを更新する機能が影響を受けます。インフラストラクチャー Filesystem ボリュームモードを使用すると、ホストされた Block モードのパフォーマンスが低下します。

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
    1
    ホステッドクラスターの名前を指定します (例: example)。
    2
    ワーカー数を指定します (例: 2)。
    3
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    4
    メモリーの値を指定します (例: 8Gi)。
    5
    CPU の値を指定します (例: 2)。
    6
    KubeVirt 仮想マシンルートボリュームをホストするストレージクラスの名前を指定します (例: ocs-storagecluster-ceph-rbd)。
    7
    ボリュームサイズを指定します (例: 64)。

    これにより、PVC 上でホストされる仮想マシンを使用してホステッドクラスターが作成されます。

5.3.2.5. KubeVirt 仮想マシンイメージキャッシュの有効化

KubeVirt 仮想マシンイメージキャッシュを使用すると、クラスターの起動時間とストレージ使用量の両方を最適化できます。KubeVirt 仮想マシンイメージキャッシュは、スマートクローニングと ReadWriteMany アクセスモードが可能なストレージクラスの使用をサポートします。スマートクローン作成の詳細は、smart-cloning を使用したデータボリュームのクローン作成 を参照してください。

イメージのキャッシュは次のように機能します。

  1. VM イメージは、ホステッドクラスターに関連付けられた PVC にインポートされます。
  2. その 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
    1
    ホステッドクラスターの名前を指定します (例: example)。
    2
    ワーカー数を指定します (例: 2)。
    3
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    4
    メモリーの値を指定します (例: 8Gi)。
    5
    CPU の値を指定します (例: 2)。
    6
    イメージキャッシュのストラテジー (例: PVC) を指定します。

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
    1
    ホステッドクラスターの名前を指定します (例: example)。
    2
    ワーカー数を指定します (例: 2)。
    3
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    4
    メモリーの値を指定します (例: 8Gi)。
    5
    CPU の値を指定します (例: 2)。
    6
    etcd ストレージクラス名を指定します (例: lvm-storageclass)。--etcd-storage-class 引数を指定しない場合は、デフォルトのストレージクラスが使用されます。

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>
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.