4.3. OpenShift Virtualization への Hosted Control Plane のデプロイ


Hosted Control Plane と OpenShift Virtualization を使用すると、KubeVirt 仮想マシンによってホストされるワーカーノードを含む OpenShift Container Platform クラスターを作成できます。OpenShift Virtualization 上の Hosted Control Plane には、次のようないくつかの利点があります。

  • Hosted Control Plane とホステッドクラスターを同じ基盤となるベアメタルインフラストラクチャーにまとめることで、リソースの使用率が向上する
  • Hosted Control Plane とホステッドクラスターを分離して強力な分離を実現する
  • ベアメタルノードのブートストラッププロセスを排除することで、クラスターのプロビジョニング時間を短縮する
  • 同じベース OpenShift Container Platform クラスターで多くのリリースを管理する

Hosted Control Plane 機能はデフォルトで有効になっています。

Hosted Control Plane のコマンドラインインターフェイス (hcp) を使用して、OpenShift Container Platform のホストされるクラスターを作成できます。ホステッドクラスターは、マネージドクラスターとして自動的にインポートされます。この自動インポート機能を無効にする場合は、「multicluster engine Operator へのホステッドクラスターの自動インポートの無効化」を参照してください。

4.3.1. OpenShift Virtualization に Hosted Control Plane をデプロイするための要件

OpenShift Virtualization に Hosted Control Plane をデプロイする準備をする際には、次の情報を考慮してください。

  • Hosted Control Plane の同じプラットフォームで、ハブクラスターとワーカーを実行します。
  • 各ホステッドクラスターに、クラスター全体で一意の名前が必要です。multicluster engine Operator によってホステッドクラスターを管理するには、ホステッドクラスター名を既存のマネージドクラスターと同じにすることはできません。
  • ホステッドクラスター名として clusters を使用しないでください。
  • ホステッドクラスターは、multicluster engine Operator のマネージドクラスターの namespace には作成できません。
  • Hosted Control Plane のストレージを設定する場合は、etcd の推奨プラクティスを考慮してください。レイテンシー要件を満たすには、各コントロールプレーンノードで実行されるすべての Hosted Control Plane の etcd インスタンス専用の高速ストレージデバイスを使用します。LVM ストレージを使用して、ホストされた etcd Pod のローカルストレージクラスを設定できます。詳細は、「推奨される etcd プラクティス」および「論理ボリュームマネージャーストレージを使用した永続ストレージ」を参照してください。

4.3.1.1. 前提条件

OpenShift Virtualization 上に OpenShift Container Platform クラスターを作成するには、以下の前提条件を満たす必要があります。

  • KUBECONFIG 環境変数で指定された OpenShift Container Platform クラスター、バージョン 4.14 以降への管理者アクセスを持っている。
  • OpenShift Container Platform 管理クラスターで、次の DNS に示すように、ワイルドカード DNS ルートが有効になっている。

    $ oc patch ingresscontroller -n openshift-ingress-operator default --type=json -p '[{ "op": "add", "path": "/spec/routeAdmission", "value": {wildcardPolicy: "WildcardsAllowed"}}]'
  • OpenShift Container Platform 管理クラスターに、OpenShift Virtualization バージョン 4.14 以降がインストールされている。詳細は、「Web コンソールを使用した OpenShift Virtualization のインストール」を参照してください。
  • OpenShift Container Platform 管理クラスターはオンプレミスのベアメタルである。
  • OpenShift Container Platform 管理クラスターは、デフォルトの Pod ネットワーク CNI として OVNKubernetes で設定されている。
  • OpenShift Container Platform 管理クラスターにはデフォルトのストレージクラスがある。詳細は、「インストール後のストレージ設定」を参照してください。次の例は、デフォルトのストレージクラスを設定する方法を示しています。

    $ oc patch storageclass ocs-storagecluster-ceph-rbd -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
  • quay.io/openshift-release-dev リポジトリーの有効なプルシークレットファイルがある。詳細は、「user-provisioned infrastructure を使用して任意の x86_64 プラットフォームに OpenShift をインストールする」を参照してください。
  • Hosted Control Plane コマンドラインインターフェイスがインストール済みである。
  • ロードバランサーを設定した。詳細は、「MetalLB の設定」を参照してください。
  • ネットワークパフォーマンスを最適化するために、KubeVirt 仮想マシンをホストする OpenShift Container Platform クラスターで 9000 以上のネットワーク最大伝送単位 (MTU) を使用している。低い MTU 設定を使用すると、ネットワーク遅延とホストされる Pod のスループットに影響があります。MTU が 9000 以上の場合にのみ、ノードプールでマルチキューを有効にします。
  • multicluster engine Operator には、少なくとも 1 つのマネージド OpenShift Container Platform クラスターがある。local-cluster は自動的にインポートされます。local-cluster の詳細は、multicluster engine Operator ドキュメントの「高度な設定」を参照してください。次のコマンドを実行して、ハブクラスターの状態を確認できます。

    $ oc get managedclusters local-cluster
  • OpenShift Virtualization 仮想マシンをホストする OpenShift Container Platform クラスターで、ライブマイグレーションを有効化できるように ReadWriteMany (RWX) ストレージクラスを使用している。

4.3.1.2. ファイアウォールのポートの要件

管理クラスター、コントロールプレーン、ホステッドクラスター間でポートが通信できるように、ファイアウォールとポートの要件を満たしていることを確認します。

  • kube-apiserver サービスはデフォルトでポート 6443 で実行され、コントロールプレーンコンポーネント間の通信には ingress アクセスが必要です。

    • NodePort 公開ストラテジーを使用する場合は、kube-apiserver サービスに割り当てられたノードポートが公開されていることを確認してください。
    • MetalLB ロードバランシングを使用する場合は、ロードバランサーの IP アドレスに使用される IP 範囲への ingress アクセスを許可します。
  • NodePort 公開ストラテジーを使用する場合は、ignition-server および Oauth-server 設定にファイアウォールルールを使用します。
  • konnectivity エージェントは、ホステッドクラスター上で双方向通信を可能にするリバーストンネルを確立し、ポート 6443 でクラスター API サーバーアドレスへの egress アクセスを必要とします。この egress アクセスを使用すると、エージェントは kube-apiserver サービスにアクセスできます。

    • クラスター API サーバーのアドレスが内部 IP アドレスの場合は、ワークロードサブネットからポート 6443 の IP アドレスへのアクセスを許可します。
    • アドレスが外部 IP アドレスの場合は、ノードからその外部 IP アドレスにポート 6443 で送信できるように許可します。
  • デフォルトのポート 6443 を変更する場合は、その変更を反映するようにルールを調整します。
  • クラスター内で実行されるワークロードに必要なポートがすべて開いていることを確認してください。
  • ファイアウォールルール、セキュリティーグループ、またはその他のアクセス制御を使用して、必要なソースだけにアクセスを制限します。必要な場合を除き、ポートを公開しないでください。
  • 実稼働環境の場合は、ロードバランサーを使用して、単一の IP アドレスによるアクセスを簡素化します。

4.3.2. コンピュートノードのライブマイグレーション

ホステッドクラスターの仮想マシン (仮想マシン) の管理クラスターが更新中またはメンテナンス中に、ホステッドクラスターのワークロードの中断を防止するためにホステッドクラスター仮想マシンを自動的にライブマイグレーションできます。その結果、KubeVirt プラットフォームのホステッドクラスターの可用性と操作に影響を与えることなく、管理クラスターを更新できます。

重要

仮想マシンがルートボリュームと kubevirt-csi CSI プロバイダーにマップされているストレージクラスの両方に ReadWriteMany (RWX) ストレージを使用していれば、KubeVirt 仮想マシンのライブマイグレーションはデフォルトで有効になります。

NodePool オブジェクトの status セクションで KubeVirtNodesLiveMigratable 条件を確認することで、ノードプール内の仮想マシンがライブマイグレーションに対応していることを確認できます。

以下は、RWX ストレージが使用されていないために仮想マシンをライブマイグレーションできない例を示しています。

仮想マシンのライブマイグレーションができない設定例

    - lastTransitionTime: "2024-10-08T15:38:19Z"
      message: |
        3 of 3 machines are not live migratable
        Machine user-np-ngst4-gw2hz: DisksNotLiveMigratable: user-np-ngst4-gw2hz is not a live migratable machine: cannot migrate VMI: PVC user-np-ngst4-gw2hz-rhcos is not shared, live migration requires that all PVCs must be shared (using ReadWriteMany access mode)
        Machine user-np-ngst4-npq7x: DisksNotLiveMigratable: user-np-ngst4-npq7x is not a live migratable machine: cannot migrate VMI: PVC user-np-ngst4-npq7x-rhcos is not shared, live migration requires that all PVCs must be shared (using ReadWriteMany access mode)
        Machine user-np-ngst4-q5nkb: DisksNotLiveMigratable: user-np-ngst4-q5nkb is not a live migratable machine: cannot migrate VMI: PVC user-np-ngst4-q5nkb-rhcos is not shared, live migration requires that all PVCs must be shared (using ReadWriteMany access mode)
      observedGeneration: 1
      reason: DisksNotLiveMigratable
      status: "False"
      type: KubeVirtNodesLiveMigratable

以下は、仮想マシンがライブマイグレーション要件を満たしている例を示しています。

仮想マシンのライブマイグレーションが可能な設定例

    - lastTransitionTime: "2024-10-08T15:38:19Z"
      message: "All is well"
      observedGeneration: 1
      reason: AsExpected
      status: "True"
      type: KubeVirtNodesLiveMigratable

通常の状況ではライブマイグレーションにより仮想マシンの中断を防止できますが、インフラストラクチャーノードの障害などのイベントが発生すると、障害が発生したノードでホストされているすべての仮想マシンが強制的に再起動される可能性があります。ライブマイグレーションを成功させるには、仮想マシンがホストされているソースノードが正しく動作している必要があります。

ノードプール内の仮想マシンのライブマイグレーションができない場合、管理クラスターのメンテナンス中にホステッドクラスターでワークロードの中断が発生する可能性があります。デフォルトでは、Hosted Control Plane コントローラーは、仮想マシンが停止される前に、ライブマイグレーションできない KubeVirt 仮想マシンでホストされているワークロードをドレインしようとします。仮想マシンが停止する前にホステッドクラスターノードをドレインすると、Pod Disruption Budget によってホステッドクラスター内のワークロードの可用性を保護できます。

4.3.3. KubeVirt プラットフォームを使用したホステッドクラスターの作成

OpenShift Container Platform 4.14 以降では、KubeVirt を使用してクラスターを作成でき、外部インフラストラクチャーを使用して作成することも可能です。

4.3.3.1. CLI を使用して KubeVirt プラットフォームでホステッドクラスターを作成する

ホステッドクラスターを作成するには、Hosted Control Plane コマンドラインインターフェイス (hcp) を使用できます。

手順

  1. 以下のコマンドを入力します。

    $ hcp create cluster kubevirt \
      --name <hosted-cluster-name> \ 1
      --node-pool-replicas <worker-count> \ 2
      --pull-secret <path-to-pull-secret> \ 3
      --memory <value-for-memory> \ 4
      --cores <value-for-cpu> \ 5
      --etcd-storage-class=<etcd-storage-class> 6
    1
    ホステッドクラスターの名前を指定します (例: example)。
    2
    ワーカー数を指定します (例: 2)。
    3
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    4
    メモリーの値を指定します (例: 6Gi)。
    5
    CPU の値を指定します (例: 2)。
    6
    etcd ストレージクラス名を指定します (例: lvm-storageclass)。
    注記

    --release-image フラグを使用すると、特定の OpenShift Container Platform リリースを使用してホステッドクラスターを設定できます。

    --node-pool-replicas フラグに従って、2 つの仮想マシンワーカーレプリカを持つクラスターに対してデフォルトのノードプールが作成されます。

  2. しばらくすると、次のコマンドを入力して、ホストされているコントロールプレーン Pod が実行されていることを確認できます。

    $ oc -n clusters-<hosted-cluster-name> get pods

    出力例

    NAME                                                  READY   STATUS    RESTARTS   AGE
    capi-provider-5cc7b74f47-n5gkr                        1/1     Running   0          3m
    catalog-operator-5f799567b7-fd6jw                     2/2     Running   0          69s
    certified-operators-catalog-784b9899f9-mrp6p          1/1     Running   0          66s
    cluster-api-6bbc867966-l4dwl                          1/1     Running   0          66s
    .
    .
    .
    redhat-operators-catalog-9d5fd4d44-z8qqk              1/1     Running   0          66s

    KubeVirt 仮想マシンによってサポートされるワーカーノードを含むホステッドクラスターは、通常、完全にプロビジョニングされるまでに 10 ~ 15 分かかります。

  3. ホステッドクラスターのステータスを確認するには、次のコマンドを入力して、対応する HostedCluster リソースを確認します。

    $ oc get --namespace clusters hostedclusters

    完全にプロビジョニングされた HostedCluster オブジェクトを示す以下の出力例を参照してください。

    NAMESPACE   NAME      VERSION   KUBECONFIG                 PROGRESS    AVAILABLE   PROGRESSING   MESSAGE
    clusters    example   4.x.0     example-admin-kubeconfig   Completed   True        False         The hosted control plane is available

    4.x.0 を、使用するサポートされている OpenShift Container Platform バージョンに置き換えます。

4.3.3.2. 外部インフラストラクチャーを使用して KubeVirt プラットフォームでホステッドクラスターを作成する

デフォルトでは、HyperShift Operator は、ホステッドクラスターのコントロールプレーン Pod と、同じクラスター内の KubeVirt ワーカー VM の両方をホストします。外部インフラストラクチャー機能を使用すると、ワーカーノード VM をコントロールプレーン Pod とは別のクラスターに配置できます。

  • 管理クラスター は HyperShift Operator を実行し、ホステッドクラスターのコントロールプレーン Pod をホストする OpenShift Container Platform クラスターです。
  • インフラストラクチャークラスター は、ホステッドクラスターの KubeVirt ワーカー VM を実行する OpenShift Container Platform クラスターです。
  • デフォルトでは、管理クラスターは VM をホストするインフラストラクチャークラスターとしても機能します。ただし、外部インフラストラクチャーの場合、管理クラスターとインフラストラクチャークラスターは異なります。

前提条件

  • KubeVirt ノードをホストする外部インフラストラクチャークラスター上に namespace が必要です。
  • 外部インフラストラクチャークラスター用の kubeconfig ファイルが必要です。

手順

hcp コマンドラインインターフェイスを使用して、ホステッドクラスターを作成できます。

  • KubeVirt ワーカーの仮想マシンをインフラストラクチャークラスターに配置するには、次の例に示すように、--infra-kubeconfig-file および --infra-namespace 引数を使用します。

    $ hcp create cluster kubevirt \
      --name <hosted-cluster-name> \ 1
      --node-pool-replicas <worker-count> \ 2
      --pull-secret <path-to-pull-secret> \ 3
      --memory <value-for-memory> \ 4
      --cores <value-for-cpu> \ 5
      --infra-namespace=<hosted-cluster-namespace>-<hosted-cluster-name> \ 6
      --infra-kubeconfig-file=<path-to-external-infra-kubeconfig> 7
    1
    ホステッドクラスターの名前を指定します (例: example)。
    2
    ワーカー数を指定します (例: 2)。
    3
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    4
    メモリーの値を指定します (例: 6Gi)。
    5
    CPU の値を指定します (例: 2)。
    6
    インフラストラクチャー namespace を指定します (例: clusters-example)。
    7
    インフラストラクチャークラスターの kubeconfig ファイルへのパスを指定します (例: /user/name/external-infra-kubeconfig)。

    このコマンドを入力すると、コントロールプレーン Pod は HyperShift Operator が実行される管理クラスターでホストされ、KubeVirt VM は別のインフラストラクチャークラスターでホストされます。

4.3.3.3. コンソールを使用したホステッドクラスターの作成

コンソールを使用して KubeVirt プラットフォームでホステッドクラスターを作成するには、次の手順を実行します。

手順

  1. OpenShift Container Platform Web コンソールを開き、管理者の認証情報を入力してログインします。
  2. コンソールヘッダーで、All Clusters が選択されていることを確認します。
  3. Infrastructure > Clusters をクリックします。
  4. Create cluster > Red Hat OpenShift Virtualization > Hosted をクリックします。
  5. Create cluster ページで、プロンプトに従ってクラスターとノードプールの詳細を入力します。

    注記
    • 事前定義された値を使用してコンソールのフィールドに自動的に入力する場合は、OpenShift Virtualization の認証情報を作成します。詳細は、オンプレミス環境の認証情報の作成 を参照してください。
    • Cluster details ページのプルシークレットは、OpenShift Container Platform リソースへのアクセスに使用する OpenShift Container Platform プルシークレットです。OpenShift Virtualization の認証情報を選択した場合、プルシークレットが自動的に入力されます。
  6. エントリーを確認し、Create をクリックします。

    Hosted cluster ビューが表示されます。

  7. Hosted cluster ビューでホストされたクラスターのデプロイメントを監視します。ホストされたクラスターに関する情報が表示されない場合は、All Clusters が選択されていることを確認し、クラスター名をクリックします。
  8. コントロールプレーンコンポーネントの準備が整うまで待ちます。このプロセスには数分かかる場合があります。
  9. ノードプールのステータスを表示するには、NodePool セクションまでスクロールします。ノードをインストールするプロセスには約 10 分かかります。Nodes をクリックして、ノードがホストされたクラスターに参加したかどうかを確認することもできます。

関連情報

4.3.4. OpenShift Virtualization 上の Hosted Control Plane のデフォルトの Ingress と DNS を設定する

すべての OpenShift Container Platform クラスターにはデフォルトのアプリケーション Ingress コントローラーが含まれており、これにはワイルドカード DNS レコードが関連付けられている必要があります。デフォルトでは、HyperShift KubeVirt プロバイダーを使用して作成されたホステッドクラスターは、自動的に KubeVirt 仮想マシンが実行される OpenShift Container Platform クラスターのサブドメインになります。

たとえば、OpenShift Container Platform クラスターには次のデフォルトの Ingress DNS エントリーがある可能性があります。

*.apps.mgmt-cluster.example.com

その結果、guest という名前が付けられ、その基礎となる OpenShift Container Platform クラスター上で実行される KubeVirt ホステッドクラスターには、次のデフォルト Ingress が設定されます。

*.apps.guest.apps.mgmt-cluster.example.com

手順

デフォルトの Ingress DNS が適切に機能するには、KubeVirt 仮想マシンをホストするクラスターでワイルドカード DNS ルートを許可する必要があります。

  • この動作は、以下のコマンドを入力して設定できます。

    $ oc patch ingresscontroller -n openshift-ingress-operator default --type=json -p '[{ "op": "add", "path": "/spec/routeAdmission", "value": {wildcardPolicy: "WildcardsAllowed"}}]'
注記

デフォルトのホステッドクラスターの Ingress を使用する場合、接続がポート 443 経由の HTTPS トラフィックに制限されます。ポート 80 経由のプレーン HTTP トラフィックは拒否されます。この制限は、デフォルトの Ingress の動作にのみ適用されます。

4.3.5. Ingress と DNS の動作のカスタマイズ

デフォルトの Ingress および DNS 動作を使用しない場合は、作成時に一意のベースドメインを使用して KubeVirt ホステッドクラスターを設定できます。このオプションでは、作成時に手動の設定手順が必要であり、クラスターの作成、ロードバランサーの作成、およびワイルドカード DNS 設定の 3 つの主要な手順が含まれます。

4.3.5.1. ベースドメインを指定するホステッドクラスターのデプロイ

ベースドメインを指定するホステッドクラスターを作成するには、次の手順を実行します。

手順

  1. 以下のコマンドを入力します。

    $ hcp create cluster kubevirt \
      --name <hosted_cluster_name> \ 1
      --node-pool-replicas <worker_count> \ 2
      --pull-secret <path_to_pull_secret> \ 3
      --memory <value_for_memory> \ 4
      --cores <value_for_cpu> \ 5
      --base-domain <basedomain> 6
    1
    ホステッドクラスターの名前を指定します。
    2
    ワーカー数を指定します (例: 2)。
    3
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    4
    メモリーの値を指定します (例: 6Gi)。
    5
    CPU の値を指定します (例: 2)。
    6
    ベースドメインを指定します (例: hypershift.lab)。

    その結果、ホストされたクラスターには、クラスター名とベースドメイン用に設定された Ingress ワイルドカード (例: .apps.example.hypershift.lab) が含まれます。ホステッドクラスターは Partial ステータスのままです。一意のベースドメインを持つホステッドクラスターを作成した後、必要な DNS レコードとロードバランサーを設定する必要があるためです。

  2. 次のコマンドを入力して、ホストされたクラスターのステータスを表示します。

    $ oc get --namespace clusters hostedclusters

    出力例

    NAME            VERSION   KUBECONFIG                       PROGRESS   AVAILABLE   PROGRESSING   MESSAGE
    example                   example-admin-kubeconfig         Partial    True        False         The hosted control plane is available

  3. 次のコマンドを入力してクラスターにアクセスします。

    $ hcp create kubeconfig --name <hosted_cluster_name> > <hosted_cluster_name>-kubeconfig
    $ oc --kubeconfig <hosted_cluster_name>-kubeconfig get co

    出力例

    NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
    console                                    4.x.0     False       False         False      30m     RouteHealthAvailable: failed to GET route (https://console-openshift-console.apps.example.hypershift.lab): Get "https://console-openshift-console.apps.example.hypershift.lab": dial tcp: lookup console-openshift-console.apps.example.hypershift.lab on 172.31.0.10:53: no such host
    ingress                                    4.x.0     True        False         True       28m     The "default" ingress controller reports Degraded=True: DegradedConditions: One or more other status conditions indicate a degraded state: CanaryChecksSucceeding=False (CanaryChecksRepetitiveFailures: Canary route checks for the default ingress controller are failing)

    4.x.0 を、使用するサポートされている OpenShift Container Platform バージョンに置き換えます。

次のステップ

出力のエラーを修正するには、「ロードバランサーのセットアップ」および「ワイルドカード DNS の設定」の手順を完了します。

注記

ホステッドクラスターがベアメタル上にある場合は、ロードバランサーサービスを設定するために MetalLB が必要になる場合があります。詳細は、「MetalLB の設定」を参照してください。

4.3.5.2. ロードバランサーのセットアップ

Ingress トラフィックを KubeVirt 仮想マシンにルーティングし、ロードバランサー IP アドレスにワイルドカード DNS エントリーを割り当てるロードバランサーサービスを設定します。

手順

  1. ホストされたクラスターの Ingress を公開する NodePort サービスがすでに存在します。ノードポートをエクスポートし、それらのポートをターゲットとするロードバランサーサービスを作成できます。

    1. 次のコマンドを入力して、HTTP ノードポートを取得します。

      $ oc --kubeconfig <hosted_cluster_name>-kubeconfig get services -n openshift-ingress router-nodeport-default -o jsonpath='{.spec.ports[?(@.name=="http")].nodePort}'

      次の手順で使用する HTTP ノードポート値をメモします。

    2. 次のコマンドを入力して、HTTPS ノードポートを取得します。

      $ oc --kubeconfig <hosted_cluster_name>-kubeconfig get services -n openshift-ingress router-nodeport-default -o jsonpath='{.spec.ports[?(@.name=="https")].nodePort}'

      次の手順で使用する HTTPS ノードポート値をメモします。

  2. 次のコマンドを入力して、ロードバランサーサービスを作成します。

    oc apply -f -
    apiVersion: v1
    kind: Service
    metadata:
      labels:
        app: <hosted_cluster_name>
      name: <hosted_cluster_name>-apps
      namespace: clusters-<hosted_cluster_name>
    spec:
      ports:
      - name: https-443
        port: 443
        protocol: TCP
        targetPort: <https_node_port> 1
      - name: http-80
        port: 80
        protocol: TCP
        targetPort: <http-node-port> 2
      selector:
        kubevirt.io: virt-launcher
      type: LoadBalancer
    1
    前の手順でメモした HTTPS ノードポート値を指定します。
    2
    前の手順でメモした HTTP ノードポート値を指定します。

4.3.5.3. ワイルドカード DNS の設定

ロードバランサーサービスの外部 IP を参照するワイルドカード DNS レコードまたは CNAME を設定します。

手順

  1. 次のコマンドを入力して外部 IP アドレスを取得します。

    $ oc -n clusters-<hosted_cluster_name> get service <hosted-cluster-name>-apps -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

    出力例

    192.168.20.30

  2. 外部 IP アドレスを参照するワイルドカード DNS エントリーを設定します。次の DNS エントリーの例を表示します。

    *.apps.<hosted_cluster_name\>.<base_domain\>.

    DNS エントリーは、クラスターの内部と外部にルーティングできる必要があります。

    DNS 解決の例

    dig +short test.apps.example.hypershift.lab
    
    192.168.20.30

  3. 次のコマンドを実行して、ホストされたクラスターのステータスが Partial から Completed に移行したことを確認します。

    $ oc get --namespace clusters hostedclusters

    出力例

    NAME            VERSION   KUBECONFIG                       PROGRESS    AVAILABLE   PROGRESSING   MESSAGE
    example         4.x.0     example-admin-kubeconfig         Completed   True        False         The hosted control plane is available

    4.x.0 を、使用するサポートされている OpenShift Container Platform バージョンに置き換えます。

4.3.6. MetalLB の設定

MetalLB を設定する前に、MetalLB Operator をインストールする必要があります。

手順

ホステッドクラスターで MetalLB を設定するには、次の手順を実行します。

  1. 次のサンプル YAML コンテンツを configure-metallb.yaml ファイルに保存して、MetalLB リソースを作成します。

    apiVersion: metallb.io/v1beta1
    kind: MetalLB
    metadata:
      name: metallb
      namespace: metallb-system
  2. 次のコマンドを入力して、YAML コンテンツを適用します。

    $ oc apply -f configure-metallb.yaml

    出力例

    metallb.metallb.io/metallb created

  3. 以下のサンプル YAML コンテンツを create-ip-address-pool.yaml ファイルに保存して、IPAddressPool リソースを作成します。

    apiVersion: metallb.io/v1beta1
    kind: IPAddressPool
    metadata:
      name: metallb
      namespace: metallb-system
    spec:
      addresses:
      - 192.168.216.32-192.168.216.122 1
    1
    ノードネットワーク内で使用可能な IP アドレスの範囲を使用してアドレスプールを作成します。IP アドレス範囲は、ネットワーク内で使用可能な IP アドレスの未使用のプールに置き換えます。
  4. 次のコマンドを入力して、YAML コンテンツを適用します。

    $ oc apply -f create-ip-address-pool.yaml

    出力例

    ipaddresspool.metallb.io/metallb created

  5. 次のサンプル YAML コンテンツを l2advertisement.yaml ファイルに保存して、L2Advertisement リソースを作成します。

    apiVersion: metallb.io/v1beta1
    kind: L2Advertisement
    metadata:
      name: l2advertisement
      namespace: metallb-system
    spec:
      ipAddressPools:
       - metallb
  6. 次のコマンドを入力して、YAML コンテンツを適用します。

    $ oc apply -f l2advertisement.yaml

    出力例

    l2advertisement.metallb.io/metallb created

関連情報

4.3.7. 追加のネットワーク、Guaranteed CPU、およびノードプールの仮想マシンのスケジュールを設定する

ノードプール用に追加のネットワークを設定する必要がある場合、仮想マシン (VM) 用の Guaranteed CPU へのアクセスを要求する場合、または KubeVirt 仮想マシンのスケジュールを管理する必要がある場合は、次の手順を参照してください。

4.3.7.1. ノードプールへの複数のネットワークの追加

デフォルトでは、ノードプールによって生成されたノードは、Pod ネットワークに割り当てられます。Multus および NetworkAttachmentDefinitions を使用すると、追加のネットワークをノードに割り当てることができます。

手順

ノードに複数のネットワークを追加するには、次のコマンドを実行して --additional-network 引数を使用します。

$ 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
  --additional-network name:<namespace/name> \ 6
  –-additional-network name:<namespace/name>
1
ホステッドクラスターの名前を指定します (例: example)。
2
ワーカーノードの数を指定します (例: 2)
3
プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
4
メモリー値を指定します (例: 8Gi)
5
CPU 値を指定します (例: 2)
6
–additional-network 引数の値を name:<namespace/name> に設定します。<namespace/name> は、NetworkAttachmentDefinition の namespace と名前に置き換えます。
4.3.7.1.1. 追加のネットワークをデフォルトとして使用する

デフォルトの Pod ネットワークを無効にすることで、追加のネットワークをノードのデフォルトネットワークとして追加できます。

手順

  • 追加のネットワークをデフォルトとしてノードに追加するには、次のコマンドを実行します。

    $ 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
      --attach-default-network false \ 6
      --additional-network name:<namespace>/<network_name> 7
    1
    ホステッドクラスターの名前を指定します (例: example)。
    2
    ワーカーノードの数を指定します (例: 2)
    3
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    4
    メモリー値を指定します (例: 8Gi)
    5
    CPU 値を指定します (例: 2)
    6
    --attach-default-network false 引数は、デフォルトの Pod ネットワークを無効にします。
    7
    ノードに追加する追加のネットワークを指定します (例: name:my-namespace/my-network)。

4.3.7.2. Guaranteed CPU リソースの要求

デフォルトでは、KubeVirt 仮想マシンはノード上の他のワークロードと CPU を共有する場合があります。これにより、仮想マシンのパフォーマンスに影響が出る可能性があります。パフォーマンスへの影響を回避するために、仮想マシン用の Guaranteed CPU へのアクセスを要求できます。

手順

  • 保証された CPU リソースを要求するには、次のコマンドを実行して --qos-class 引数を Guaranteed に設定します。

    $ 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
      --qos-class Guaranteed 6
    1
    ホステッドクラスターの名前を指定します (例: example)。
    2
    ワーカーノードの数を指定します (例: 2)
    3
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    4
    メモリー値を指定します (例: 8Gi)
    5
    CPU 値を指定します (例: 2)
    6
    --qos-class Guaranteed 引数は、指定された数の CPU リソースが仮想マシンに割り当てられることを保証します。

4.3.7.3. ノードセットに KubeVirt 仮想マシンをスケジュールする

デフォルトでは、ノードプールによって作成された KubeVirt 仮想マシンは、使用可能な任意のノードにスケジュールされます。KubeVirt 仮想マシンは、仮想マシンを実行するのに十分な容量を持つ特定のノードセットにスケジュールすることもできます。

手順

  • 特定のノードセット上のノードプール内で KubeVirt 仮想マシンをスケジュールするには、次のコマンドを実行して -- 仮想マシン -node-selector 引数を使用します。

    $ 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
      --vm-node-selector <label_key>=<label_value>,<label_key>=<label_value> 6
    1
    ホステッドクラスターの名前を指定します (例: example)。
    2
    ワーカーノードの数を指定します (例: 2)
    3
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    4
    メモリー値を指定します (例: 8Gi)
    5
    CPU 値を指定します (例: 2)
    6
    --vm-node-selector フラグは、キーと値のペアを含む特定のノードセットを定義します。<label_key><label_value> をそれぞれラベルのキーと値に置き換えます。

4.3.8. ノードプールのスケーリング

oc scale コマンドを使用して、ノードプールを手動でスケーリングできます。

手順

  1. 以下のコマンドを実行します。

    NODEPOOL_NAME=${CLUSTER_NAME}-work
    NODEPOOL_REPLICAS=5
    
    $ oc scale nodepool/$NODEPOOL_NAME --namespace clusters --replicas=$NODEPOOL_REPLICAS
  2. しばらくしてから、次のコマンドを入力して、ノードプールのステータスを確認します。

    $ oc --kubeconfig $CLUSTER_NAME-kubeconfig get nodes

    出力例

    NAME                  STATUS   ROLES    AGE     VERSION
    example-9jvnf         Ready    worker   97s     v1.27.4+18eadca
    example-n6prw         Ready    worker   116m    v1.27.4+18eadca
    example-nc6g4         Ready    worker   117m    v1.27.4+18eadca
    example-thp29         Ready    worker   4m17s   v1.27.4+18eadca
    example-twxns         Ready    worker   88s     v1.27.4+18eadca

4.3.8.1. ノードプールの追加

名前、レプリカの数、およびメモリーや CPU 要件などの追加情報を指定して、ホステッドクラスターのノードプールを作成できます。

手順

  1. ノードプールを作成するには、次の情報を入力します。この例では、ノードプールには VM に割り当てられたより多くの CPU があります。

    export NODEPOOL_NAME=${CLUSTER_NAME}-extra-cpu
    export WORKER_COUNT="2"
    export MEM="6Gi"
    export CPU="4"
    export DISK="16"
    
    $ hcp create nodepool kubevirt \
      --cluster-name $CLUSTER_NAME \
      --name $NODEPOOL_NAME \
      --node-count $WORKER_COUNT \
      --memory $MEM \
      --cores $CPU \
      --root-volume-size $DISK
  2. clusters namespace 内の nodepool リソースをリスト表示して、ノードプールのステータスを確認します。

    $ oc get nodepools --namespace clusters

    出力例

    NAME                      CLUSTER         DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION   UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
    example                   example         5               5               False         False        4.x.0
    example-extra-cpu         example         2                               False         False                  True              True             Minimum availability requires 2 replicas, current 0 available

    4.x.0 を、使用するサポートされている OpenShift Container Platform バージョンに置き換えます。

  3. しばらくしてから、次のコマンドを入力してノードプールのステータスを確認できます。

    $ oc --kubeconfig $CLUSTER_NAME-kubeconfig get nodes

    出力例

    NAME                      STATUS   ROLES    AGE     VERSION
    example-9jvnf             Ready    worker   97s     v1.27.4+18eadca
    example-n6prw             Ready    worker   116m    v1.27.4+18eadca
    example-nc6g4             Ready    worker   117m    v1.27.4+18eadca
    example-thp29             Ready    worker   4m17s   v1.27.4+18eadca
    example-twxns             Ready    worker   88s     v1.27.4+18eadca
    example-extra-cpu-zh9l5   Ready    worker   2m6s    v1.27.4+18eadca
    example-extra-cpu-zr8mj   Ready    worker   102s    v1.27.4+18eadca

  4. 次のコマンドを入力して、ノードプールが予期したステータスになっていることを確認します。

    $ oc get nodepools --namespace clusters

    出力例

    NAME                      CLUSTER         DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION   UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
    example                   example         5               5               False         False        4.x.0
    example-extra-cpu         example         2               2               False         False        4.x.0

    4.x.0 を、使用するサポートされている OpenShift Container Platform バージョンに置き換えます。

関連情報

4.3.9. OpenShift Virtualization でのホステッドクラスターの作成の検証

ホステッドクラスターが正常に作成されたことを確認するには、次の手順を完了します。

手順

  1. 次のコマンドを入力して、HostedCluster リソースが completed 状態に移行したことを確認します。

    $ oc get --namespace clusters hostedclusters <hosted_cluster_name>

    出力例

    NAMESPACE   NAME      VERSION   KUBECONFIG                 PROGRESS    AVAILABLE   PROGRESSING   MESSAGE
    clusters    example   4.12.2    example-admin-kubeconfig   Completed   True        False         The hosted control plane is available

  2. 次のコマンドを入力して、ホステッドクラスター内のすべてのクラスターオペレーターがオンラインであることを確認します。

    $ hcp create kubeconfig --name <hosted_cluster_name> > <hosted_cluster_name>-kubeconfig
    $ oc get co --kubeconfig=<hosted_cluster_name>-kubeconfig

    出力例

    NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
    console                                    4.12.2   True        False         False      2m38s
    csi-snapshot-controller                    4.12.2   True        False         False      4m3s
    dns                                        4.12.2   True        False         False      2m52s
    image-registry                             4.12.2   True        False         False      2m8s
    ingress                                    4.12.2   True        False         False      22m
    kube-apiserver                             4.12.2   True        False         False      23m
    kube-controller-manager                    4.12.2   True        False         False      23m
    kube-scheduler                             4.12.2   True        False         False      23m
    kube-storage-version-migrator              4.12.2   True        False         False      4m52s
    monitoring                                 4.12.2   True        False         False      69s
    network                                    4.12.2   True        False         False      4m3s
    node-tuning                                4.12.2   True        False         False      2m22s
    openshift-apiserver                        4.12.2   True        False         False      23m
    openshift-controller-manager               4.12.2   True        False         False      23m
    openshift-samples                          4.12.2   True        False         False      2m15s
    operator-lifecycle-manager                 4.12.2   True        False         False      22m
    operator-lifecycle-manager-catalog         4.12.2   True        False         False      23m
    operator-lifecycle-manager-packageserver   4.12.2   True        False         False      23m
    service-ca                                 4.12.2   True        False         False      4m41s
    storage                                    4.12.2   True        False         False      4m43s

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.