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
) を使用できます。
手順
以下のコマンドを入力します。
$ 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
注記--release-image
フラグを使用すると、特定の OpenShift Container Platform リリースを使用してホステッドクラスターを設定できます。--node-pool-replicas
フラグに従って、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 分かかります。
ホステッドクラスターのステータスを確認するには、次のコマンドを入力して、対応する
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
このコマンドを入力すると、コントロールプレーン Pod は HyperShift Operator が実行される管理クラスターでホストされ、KubeVirt VM は別のインフラストラクチャークラスターでホストされます。
4.3.3.3. コンソールを使用したホステッドクラスターの作成
コンソールを使用して KubeVirt プラットフォームでホステッドクラスターを作成するには、次の手順を実行します。
手順
- OpenShift Container Platform Web コンソールを開き、管理者の認証情報を入力してログインします。
- コンソールヘッダーで、All Clusters が選択されていることを確認します。
- Infrastructure > Clusters をクリックします。
- Create cluster > Red Hat OpenShift Virtualization > Hosted をクリックします。
Create cluster ページで、プロンプトに従ってクラスターとノードプールの詳細を入力します。
注記- 事前定義された値を使用してコンソールのフィールドに自動的に入力する場合は、OpenShift Virtualization の認証情報を作成します。詳細は、オンプレミス環境の認証情報の作成 を参照してください。
- Cluster details ページのプルシークレットは、OpenShift Container Platform リソースへのアクセスに使用する OpenShift Container Platform プルシークレットです。OpenShift Virtualization の認証情報を選択した場合、プルシークレットが自動的に入力されます。
エントリーを確認し、Create をクリックします。
Hosted cluster ビューが表示されます。
- Hosted cluster ビューでホストされたクラスターのデプロイメントを監視します。ホストされたクラスターに関する情報が表示されない場合は、All Clusters が選択されていることを確認し、クラスター名をクリックします。
- コントロールプレーンコンポーネントの準備が整うまで待ちます。このプロセスには数分かかる場合があります。
- ノードプールのステータスを表示するには、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. ベースドメインを指定するホステッドクラスターのデプロイ
ベースドメインを指定するホステッドクラスターを作成するには、次の手順を実行します。
手順
以下のコマンドを入力します。
$ 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
その結果、ホストされたクラスターには、クラスター名とベースドメイン用に設定された Ingress ワイルドカード (例:
.apps.example.hypershift.lab
) が含まれます。ホステッドクラスターはPartial
ステータスのままです。一意のベースドメインを持つホステッドクラスターを作成した後、必要な DNS レコードとロードバランサーを設定する必要があるためです。次のコマンドを入力して、ホストされたクラスターのステータスを表示します。
$ 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
次のコマンドを入力してクラスターにアクセスします。
$ 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 エントリーを割り当てるロードバランサーサービスを設定します。
手順
ホストされたクラスターの Ingress を公開する
NodePort
サービスがすでに存在します。ノードポートをエクスポートし、それらのポートをターゲットとするロードバランサーサービスを作成できます。次のコマンドを入力して、HTTP ノードポートを取得します。
$ oc --kubeconfig <hosted_cluster_name>-kubeconfig get services -n openshift-ingress router-nodeport-default -o jsonpath='{.spec.ports[?(@.name=="http")].nodePort}'
次の手順で使用する HTTP ノードポート値をメモします。
次のコマンドを入力して、HTTPS ノードポートを取得します。
$ oc --kubeconfig <hosted_cluster_name>-kubeconfig get services -n openshift-ingress router-nodeport-default -o jsonpath='{.spec.ports[?(@.name=="https")].nodePort}'
次の手順で使用する HTTPS ノードポート値をメモします。
次のコマンドを入力して、ロードバランサーサービスを作成します。
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
4.3.5.3. ワイルドカード DNS の設定
ロードバランサーサービスの外部 IP を参照するワイルドカード DNS レコードまたは CNAME を設定します。
手順
次のコマンドを入力して外部 IP アドレスを取得します。
$ oc -n clusters-<hosted_cluster_name> get service <hosted-cluster-name>-apps -o jsonpath='{.status.loadBalancer.ingress[0].ip}'
出力例
192.168.20.30
外部 IP アドレスを参照するワイルドカード DNS エントリーを設定します。次の DNS エントリーの例を表示します。
*.apps.<hosted_cluster_name\>.<base_domain\>.
DNS エントリーは、クラスターの内部と外部にルーティングできる必要があります。
DNS 解決の例
dig +short test.apps.example.hypershift.lab 192.168.20.30
次のコマンドを実行して、ホストされたクラスターのステータスが
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 を設定するには、次の手順を実行します。
次のサンプル YAML コンテンツを
configure-metallb.yaml
ファイルに保存して、MetalLB
リソースを作成します。apiVersion: metallb.io/v1beta1 kind: MetalLB metadata: name: metallb namespace: metallb-system
次のコマンドを入力して、YAML コンテンツを適用します。
$ oc apply -f configure-metallb.yaml
出力例
metallb.metallb.io/metallb created
以下のサンプル 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 アドレスの未使用のプールに置き換えます。
次のコマンドを入力して、YAML コンテンツを適用します。
$ oc apply -f create-ip-address-pool.yaml
出力例
ipaddresspool.metallb.io/metallb created
次のサンプル YAML コンテンツを
l2advertisement.yaml
ファイルに保存して、L2Advertisement
リソースを作成します。apiVersion: metallb.io/v1beta1 kind: L2Advertisement metadata: name: l2advertisement namespace: metallb-system spec: ipAddressPools: - metallb
次のコマンドを入力して、YAML コンテンツを適用します。
$ oc apply -f l2advertisement.yaml
出力例
l2advertisement.metallb.io/metallb created
関連情報
- MetalLB の詳細は、MetalLB Operator のインストール を参照してください。
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>
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
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
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
4.3.8. ノードプールのスケーリング
oc scale
コマンドを使用して、ノードプールを手動でスケーリングできます。
手順
以下のコマンドを実行します。
NODEPOOL_NAME=${CLUSTER_NAME}-work NODEPOOL_REPLICAS=5 $ oc scale nodepool/$NODEPOOL_NAME --namespace clusters --replicas=$NODEPOOL_REPLICAS
しばらくしてから、次のコマンドを入力して、ノードプールのステータスを確認します。
$ 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 要件などの追加情報を指定して、ホステッドクラスターのノードプールを作成できます。
手順
ノードプールを作成するには、次の情報を入力します。この例では、ノードプールには 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
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 バージョンに置き換えます。しばらくしてから、次のコマンドを入力してノードプールのステータスを確認できます。
$ 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
次のコマンドを入力して、ノードプールが予期したステータスになっていることを確認します。
$ 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 でのホステッドクラスターの作成の検証
ホステッドクラスターが正常に作成されたことを確認するには、次の手順を完了します。
手順
次のコマンドを入力して、
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
次のコマンドを入力して、ホステッドクラスター内のすべてのクラスターオペレーターがオンラインであることを確認します。
$ 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