ホーム
製品
OpenShift Container Platform
4.17
Hosted Control Plane
4.3. OpenShift Virtualization への Hosted Control Plane のデプロイ

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 をデプロイする準備をする際には、次の情報を考慮してください。

管理クラスターはベアメタル上で実行してください。
各ホステッドクラスターの名前がクラスター全体で一意である。
ホステッドクラスター名として 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 ルートが有効になっている。次のコマンドを参照してください。

$ 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 ネットワーク Container Network Interface (CNI) として OVNKubernetes を使用するように設定されている。CNI が OVN-Kubernetes の場合にのみ、ノードのライブマイグレーションがサポートされます。
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 以上の場合にのみ、ノードプールでマルチキューを有効にします。
重要
インストール後のタスクとしてクラスターの MTU 値を変更することはできません。
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 のコマンドラインインターフェイス (CLI) hcp を使用できます。

手順

次のコマンドを入力して、KubeVirt プラットフォームでホステッドクラスターを作成します。
```
$ hcp create cluster kubevirt \
  --name <hosted_cluster_name> \
```
1
```
  --node-pool-replicas <node_pool_replica_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
ホステッドクラスターの名前 (例: my-hosted-cluster) を指定します。
2
ノードプールのレプリカ数を指定します (例: 3)。レプリカ数は 0 以上で指定する必要があります。指定したとおりの数のノードが作成されます。それ以外の場合、ノードプールは作成されません。
3
プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
4
メモリーの値を指定します (例: 6Gi)。
5
CPU の値を指定します (例: 2)。
6
etcd ストレージクラス名を指定します (例: lvm-storageclass)。
注記
--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    my-hosted-cluster   <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
ホステッドクラスターの名前 (例: my-hosted-cluster) を指定します。
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 プラットフォームでホステッドクラスターを作成するには、次の手順を実行します。

手順

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
1
ホステッドクラスターの名前を指定します。
2
ワーカー数を指定します (例: 2)。
3
プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
4
メモリーの値を指定します (例: 6Gi)。
5
CPU の値を指定します (例: 2)。
6
ベースドメインを指定します (例: hypershift.lab)。
その結果、ホステッドクラスターには、クラスター名とベースドメイン用に設定された 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 サービスがすでに存在します。ノードポートをエクスポートし、それらのポートをターゲットとするロードバランサーサービスを作成できます。
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 ノードポート値をメモします。

YAML ファイルに次の情報を入力します。

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>


  - name: http-80
    port: 80
    protocol: TCP
    targetPort: <http_node_port>


  selector:
    kubevirt.io: virt-launcher
  type: LoadBalancer

1: 前の手順でメモした HTTPS ノードポート値を指定します。
2: 前の手順でメモした HTTP ノードポート値を指定します。

次のコマンドを実行してロードバランサーサービスを作成します。
```
$ oc create -f <file_name>.yaml
```

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
```

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

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

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

手順

特定のノードセット上のノードプール内で KubeVirt 仮想マシンをスケジュールするには、次のコマンドを実行して --vm-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
ホステッドクラスターの名前 (例: my-hosted-cluster) を指定します。
2
ワーカーノードの数を指定します (例: 2)。
3
プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
4
メモリーの値を指定します (例: 8Gi)。
5
CPU の値を指定します (例: 2)。
6
--vm-node-selector フラグは、キーと値のペアを含む特定のノードセットを定義します。<label_key> はラベルのキーに置き換え、<label_value> はラベルの値に置き換えます。

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

4.3.10. ホステッドクラスターでカスタム API サーバー証明書を設定する
リンクのコピー

API サーバーのカスタム証明書を設定するには、HostedCluster 設定の spec.configuration.apiServer セクションで証明書の詳細を指定します。

カスタム証明書は、Day 1 操作または Day 2 操作の中で設定できます。ただし、サービス公開ストラテジーはホステッドクラスターの作成中に設定した後は変更できないため、設定する予定の Kubernetes API サーバーのホスト名を知っておく必要があります。

前提条件

管理クラスターにカスタム証明書が含まれる Kubernetes シークレットを作成しました。シークレットには次の鍵が含まれています。
- tls.crt: 証明書
- tls.key: 秘密鍵
HostedCluster 設定にロードバランサーを使用するサービス公開ストラテジーが含まれている場合は、証明書のサブジェクト代替名 (SAN) が内部 API エンドポイント (api-int) と競合しないことを確認してください。内部 API エンドポイントは、プラットフォームによって自動的に作成および管理されます。カスタム証明書と内部 API エンドポイントの両方で同じホスト名を使用すると、ルーティングの競合が発生する可能性があります。このルールの唯一の例外は、Private または PublicAndPrivate 設定で AWS をプロバイダーとして使用する場合です。このような場合、SAN の競合はプラットフォームによって管理されます。
証明書は外部 API エンドポイントに対して有効である必要があります。
証明書の有効期間は、クラスターの予想されるライフサイクルと一致します。

手順

次のコマンドを入力して、カスタム証明書を使用してシークレットを作成します。

$ oc create secret tls sample-hosted-kas-custom-cert \
  --cert=path/to/cert.crt \
  --key=path/to/key.key \
  -n <hosted_cluster_namespace>

次の例に示すように、カスタム証明書の詳細を使用して HostedCluster 設定を更新します。

spec:
  configuration:
    apiServer:
      servingCerts:
        namedCertificates:
        - names:


          - api-custom-cert-sample-hosted.sample-hosted.example.com
          servingCertificate:


            name: sample-hosted-kas-custom-cert

1: 証明書が有効な DNS の名前のリスト。
2: カスタム証明書が含まれるシークレットの名前。

次のコマンドを入力して、HostedCluster 設定に変更を適用します。
```
$ oc apply -f <hosted_cluster_config>.yaml
```

検証

API サーバー Pod をチェックして、新しい証明書がマウントされていることを確認します。
カスタムドメイン名を使用して API サーバーへの接続をテストします。
ブラウザーで、または openssl などのツールを使用して、証明書の詳細を確認します。

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

4.3.1. OpenShift Virtualization に Hosted Control Plane をデプロイするための要件
リンクのコピー

4.3.1.1. 前提条件
リンクのコピー

4.3.1.2. ファイアウォールのポートの要件
リンクのコピー

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

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

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

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

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

4.3.4. OpenShift Virtualization 上の Hosted Control Plane のデフォルトの Ingress と DNS を設定する
リンクのコピー

4.3.5. Ingress と DNS の動作のカスタマイズ
リンクのコピー

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

4.3.5.2. ロードバランサーのセットアップ
リンクのコピー

4.3.5.3. ワイルドカード DNS の設定
リンクのコピー

4.3.6. MetalLB の設定
リンクのコピー

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

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

4.3.7.1.1. 追加のネットワークをデフォルトとして使用する
リンクのコピー

4.3.7.2. Guaranteed CPU リソースの要求
リンクのコピー

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

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

4.3.8.1. ノードプールの追加
リンクのコピー

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

4.3.10. ホステッドクラスターでカスタム API サーバー証明書を設定する
リンクのコピー

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

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

4.3.1. OpenShift Virtualization に Hosted Control Plane をデプロイするための要件リンクのコピーリンクがクリップボードにコピーされました!

4.3.1.1. 前提条件リンクのコピーリンクがクリップボードにコピーされました!

4.3.1.2. ファイアウォールのポートの要件リンクのコピーリンクがクリップボードにコピーされました!

4.3.2. コンピュートノードのライブマイグレーションリンクのコピーリンクがクリップボードにコピーされました!

4.3.3. KubeVirt プラットフォームを使用したホステッドクラスターの作成リンクのコピーリンクがクリップボードにコピーされました!

4.3.3.1. CLI を使用して KubeVirt プラットフォームでホステッドクラスターを作成するリンクのコピーリンクがクリップボードにコピーされました!

4.3.3.2. 外部インフラストラクチャーを使用して KubeVirt プラットフォームでホステッドクラスターを作成するリンクのコピーリンクがクリップボードにコピーされました!

4.3.3.3. コンソールを使用したホステッドクラスターの作成リンクのコピーリンクがクリップボードにコピーされました!

4.3.4. OpenShift Virtualization 上の Hosted Control Plane のデフォルトの Ingress と DNS を設定するリンクのコピーリンクがクリップボードにコピーされました!

4.3.5. Ingress と DNS の動作のカスタマイズリンクのコピーリンクがクリップボードにコピーされました!

4.3.5.1. ベースドメインを指定するホステッドクラスターのデプロイリンクのコピーリンクがクリップボードにコピーされました!

4.3.5.2. ロードバランサーのセットアップリンクのコピーリンクがクリップボードにコピーされました!

4.3.5.3. ワイルドカード DNS の設定リンクのコピーリンクがクリップボードにコピーされました!

4.3.6. MetalLB の設定リンクのコピーリンクがクリップボードにコピーされました!

4.3.7. 追加のネットワーク、Guaranteed CPU、およびノードプールの仮想マシンのスケジュールを設定するリンクのコピーリンクがクリップボードにコピーされました!

4.3.7.1. ノードプールへの複数のネットワークの追加リンクのコピーリンクがクリップボードにコピーされました!

4.3.7.1.1. 追加のネットワークをデフォルトとして使用するリンクのコピーリンクがクリップボードにコピーされました!

4.3.7.2. Guaranteed CPU リソースの要求リンクのコピーリンクがクリップボードにコピーされました!

4.3.7.3. ノードセットに KubeVirt 仮想マシンをスケジュールするリンクのコピーリンクがクリップボードにコピーされました!

4.3.8. ノードプールのスケーリングリンクのコピーリンクがクリップボードにコピーされました!

4.3.8.1. ノードプールの追加リンクのコピーリンクがクリップボードにコピーされました!

4.3.9. OpenShift Virtualization でのホステッドクラスターの作成の検証リンクのコピーリンクがクリップボードにコピーされました!

4.3.10. ホステッドクラスターでカスタム API サーバー証明書を設定するリンクのコピーリンクがクリップボードにコピーされました!

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

4.3.1. OpenShift Virtualization に Hosted Control Plane をデプロイするための要件
リンクのコピー

4.3.1.1. 前提条件
リンクのコピー

4.3.1.2. ファイアウォールのポートの要件
リンクのコピー

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

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

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

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

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

4.3.4. OpenShift Virtualization 上の Hosted Control Plane のデフォルトの Ingress と DNS を設定する
リンクのコピー

4.3.5. Ingress と DNS の動作のカスタマイズ
リンクのコピー

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

4.3.5.2. ロードバランサーのセットアップ
リンクのコピー

4.3.5.3. ワイルドカード DNS の設定
リンクのコピー

4.3.6. MetalLB の設定
リンクのコピー

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

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

4.3.7.1.1. 追加のネットワークをデフォルトとして使用する
リンクのコピー

4.3.7.2. Guaranteed CPU リソースの要求
リンクのコピー

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

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

4.3.8.1. ノードプールの追加
リンクのコピー

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

4.3.10. ホステッドクラスターでカスタム API サーバー証明書を設定する
リンクのコピー