6.2. 非接続環境で OpenShift Virtualization に Hosted Control Plane をデプロイする
Hosted Control Plane を非接続環境でデプロイする場合、使用するプラットフォームに応じて手順の一部が異なります。以下の手順は、OpenShift Virtualization へのデプロイに固有のものです。
6.2.1. 前提条件
- 管理クラスターとして機能する、非接続の OpenShift Container Platform 環境がある。
- イメージをミラーリングするための内部レジストリーがある。詳細は、非接続インストールミラーリングについて を参照してください。
6.2.2. 非接続環境で Hosted Control Plane のイメージミラーリングを設定する
イメージミラーリングは、registry.redhat.com
や quay.io
などの外部レジストリーからイメージを取得し、プライベートレジストリーに保存するプロセスです。
次の手順では、ImageSetConfiguration
オブジェクトを使用するバイナリーである、oc-mirror
ツールが使用されます。このファイルで、以下の情報を指定できます。
-
ミラーリングする OpenShift Container Platform バージョン。バージョンは
quay.io
にあります。 - ミラーリングする追加の Operator。パッケージは個別に選択します。
- リポジトリーに追加する追加のイメージ。
前提条件
ミラーリングプロセスを開始する前に、レジストリーサーバーが実行されていることを確認する。
手順
イメージのミラーリングを設定するには、以下の手順を実行します。
-
${HOME}/.docker/config.json
ファイルが、ミラーリング元のレジストリーとイメージのプッシュ先のプライベートレジストリーで更新されていることを確認します。 次の例を使用して、ミラーリングに使用する
ImageSetConfiguration
オブジェクトを作成します。環境に合わせて必要に応じて値を置き換えます。apiVersion: mirror.openshift.io/v1alpha2 kind: ImageSetConfiguration storageConfig: registry: imageURL: registry.<dns.base.domain.name>:5000/openshift/release/metadata:latest 1 mirror: platform: channels: - name: candidate-4.17 minVersion: <4.x.y-build> 2 maxVersion: <4.x.y-build> 3 type: ocp kubeVirtContainer: true 4 graph: true additionalImages: - name: quay.io/karmab/origin-keepalived-ipfailover:latest - name: quay.io/karmab/kubectl:latest - name: quay.io/karmab/haproxy:latest - name: quay.io/karmab/mdns-publisher:latest - name: quay.io/karmab/origin-coredns:latest - name: quay.io/karmab/curl:latest - name: quay.io/karmab/kcli:latest - name: quay.io/user-name/trbsht:latest - name: quay.io/user-name/hypershift:BMSelfManage-v4.17 - name: registry.redhat.io/openshift4/ose-kube-rbac-proxy:v4.10 operators: - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.17 packages: - name: lvms-operator - name: local-storage-operator - name: odf-csi-addons-operator - name: odf-operator - name: mcg-operator - name: ocs-operator - name: metallb-operator - name: kubevirt-hyperconverged 5
- 1
<dns.base.domain.name>
は、DNS ベースドメイン名に置き換えます。- 2 3
<4.x.y-build>
は、使用するサポート対象の OpenShift Container Platform バージョンに置き換えます。- 4
- KubeVirt プロバイダーの Red Hat Enterprise Linux CoreOS (RHCOS) ブートイメージのコンテナーディスクイメージもミラーリングする場合は、このオプションのフラグを
true
に設定します。このフラグは oc-mirror v2 でのみ使用できます。 - 5
- KubeVirt プロバイダーを使用するデプロイメントの場合は、この行を含めます。
次のコマンドを入力して、ミラーリングプロセスを開始します。
$ oc-mirror --v2 --config imagesetconfig.yaml docker://${REGISTRY}
ミラーリングプロセスが完了すると、
oc-mirror-workspace/results-XXXXXX/
という名前の新しいフォルダーが作成されます。このフォルダーには、ホステッドクラスターに適用する IDMS とカタログソースが含まれています。imagesetconfig.yaml
ファイルを次のように設定して、OpenShift Container Platform のナイトリーバージョンまたは CI バージョンをミラーリングします。apiVersion: mirror.openshift.io/v2alpha1 kind: ImageSetConfiguration mirror: platform: graph: true release: registry.ci.openshift.org/ocp/release:<4.x.y-build> 1 kubeVirtContainer: true 2 # ...
次のコマンドを入力して、ファイルに変更を適用します。
$ oc-mirror --v2 --config imagesetconfig.yaml docker://${REGISTRY}
- 非接続ネットワークへのインストール の手順に従って、最新の multicluster engine Operator イメージをミラーリングします。
6.2.3. 管理クラスターでのオブジェクトの適用
ミラーリングプロセスが完了したら、管理クラスターに 2 つのオブジェクトを適用する必要があります。
-
ImageContentSourcePolicy
(ICSP) またはImageDigestMirrorSet
(IDMS) - カタログソース
oc-mirror
ツールを使用すると、出力アーティファクトは oc-mirror-workspace/results-XXXXXX/
という名前のフォルダーに保存されます。
ICSP または IDMS は、ノードを再起動せずに、各ノードの kubelet を再起動する MachineConfig
の変更を開始します。ノードが READY
としてマークされたら、新しく生成されたカタログソースを適用する必要があります。
カタログソースは、カタログイメージのダウンロードや処理を行い、そのイメージに含まれるすべての PackageManifests
を取得するなど、openshift-marketplace
Operator でアクションを開始します。
手順
新しいソースを確認するには、新しい
CatalogSource
をソースとして使用して次のコマンドを実行します。$ oc get packagemanifest
アーティファクトを適用するには、次の手順を実行します。
次のコマンドを入力して、ICSP または IDMS アーティファクトを作成します。
$ oc apply -f oc-mirror-workspace/results-XXXXXX/imageContentSourcePolicy.yaml
ノードの準備が完了するまで待ってから、次のコマンドを入力します。
$ oc apply -f catalogSource-XXXXXXXX-index.yaml
OLM カタログをミラーリングし、ホステッドクラスターがミラーを参照するように設定します。
管理
(デフォルト) OLMCatalogPlacement モードを使用する場合、OLM カタログに使用されるイメージストリームは、管理クラスター上の ICSP からのオーバーライド情報で自動的に修正されません。-
OLM カタログが元の名前とタグを使用して内部レジストリーに適切にミラーリングされている場合は、
hypershift.openshift.io/olm-catalogs-is-registry-overrides
アノテーションをHostedCluster
リソースに追加します。形式は"sr1=dr1,sr2=dr2"
です。ソースレジストリーの文字列がキーで、宛先レジストリーが値です。 OLM カタログのイメージストリームメカニズムを回避するには、
HostedCluster
リソースで次の 4 つのアノテーションを使用して、OLM Operator カタログに使用する 4 つのイメージのアドレスを直接指定します。-
hypershift.openshift.io/certified-operators-catalog-image
-
hypershift.openshift.io/community-operators-catalog-image
-
hypershift.openshift.io/redhat-marketplace-catalog-image
-
hypershift.openshift.io/redhat-operators-catalog-image
-
-
OLM カタログが元の名前とタグを使用して内部レジストリーに適切にミラーリングされている場合は、
この場合、イメージストリームは作成されないため、Operator の更新を取得するために内部ミラーを更新するときに、アノテーションの値を更新する必要があります。
次のステップ
Hosted Control Plane の非接続インストールのために multicluster engine Operator をデプロイする の手順を実行して、multicluster engine Operator をデプロイします。
6.2.4. Hosted Control Plane の非接続インストールのために multicluster engine Operator をデプロイする
multicluster engine for Kubernetes Operator は、複数のプロバイダーでクラスターをデプロイする場合に重要な役割を果たします。multicluster engine Operator がインストールされていない場合は、次のドキュメントを参照して、インストールの前提条件と手順を確認してください。
6.2.5. Hosted Control Plane の非接続インストールのために TLS 証明書を設定する
非接続デプロイメントで適切な機能を確保するには、管理クラスターとホステッドクラスターのワーカーノードでレジストリー CA 証明書を設定する必要があります。
6.2.5.1. 管理クラスターにレジストリー CA を追加する
管理クラスターにレジストリー CA を追加するには、次の手順を実行します。
手順
次の例のような config map を作成します。
apiVersion: v1 kind: ConfigMap metadata: name: <config_map_name> 1 namespace: <config_map_namespace> 2 data: 3 <registry_name>..<port>: | 4 -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- <registry_name>..<port>: | -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- <registry_name>..<port>: | -----BEGIN CERTIFICATE----- -----END CERTIFICATE-----
クラスター全体のオブジェクト
image.config.openshift.io
にパッチを適用して、次の仕様を含めます。spec: additionalTrustedCA: - name: registry-config
このパッチの結果、コントロールプレーンノードがプライベートレジストリーからイメージを取得できるようになります。また、HyperShift Operator がホステッドクラスターのデプロイメント用の OpenShift Container Platform ペイロードを抽出できるようになります。
オブジェクトにパッチを適用するプロセスが完了するまでに数分かかる場合があります。
6.2.5.2. ホステッドクラスターのワーカーノードにレジストリー CA を追加する
ホステッドクラスターのデータプレーンワーカーがプライベートレジストリーからイメージを取得できるようにするために、ワーカーノードにレジストリー CA を追加する必要があります。
手順
hc.spec.additionalTrustBundle
ファイルに次の仕様を追加します。spec: additionalTrustBundle: - name: user-ca-bundle 1
- 1
user-ca-bundle
エントリーは、次の手順で作成する config map です。
HostedCluster
オブジェクトの作成先と同じ namespace で、user-ca-bundle
config map を作成します。config map は次の例のようになります。apiVersion: v1 data: ca-bundle.crt: | // Registry1 CA -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- // Registry2 CA -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- // Registry3 CA -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- kind: ConfigMap metadata: name: user-ca-bundle namespace: <hosted_cluster_namespace> 1
- 1
HostedCluster
オブジェクトの作成先の namespace を指定します。
6.2.6. OpenShift Virtualization でのホステッドクラスターの作成
ホステッドクラスターは、コントロールプレーンと API エンドポイントが管理クラスターでホストされている OpenShift Container Platform クラスターです。ホステッドクラスターには、コントロールプレーンとそれに対応するデータプレーンが含まれます。
6.2.6.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 プラクティス」および「論理ボリュームマネージャーストレージを使用した永続ストレージ」を参照してください。
6.2.6.2. CLI を使用して KubeVirt プラットフォームでホステッドクラスターを作成する
ホステッドクラスターを作成するには、Hosted Control Plane のコマンドラインインターフェイス 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
注記--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 バージョンに置き換えます。
6.2.6.3. 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 の動作にのみ適用されます。
6.2.6.4. Ingress と DNS の動作のカスタマイズ
デフォルトの Ingress および DNS 動作を使用しない場合は、作成時に一意のベースドメインを使用して KubeVirt ホステッドクラスターを設定できます。このオプションでは、作成時に手動の設定手順が必要であり、クラスターの作成、ロードバランサーの作成、およびワイルドカード DNS 設定の 3 つの主要な手順が含まれます。
6.2.6.4.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 の設定」を参照してください。
6.2.6.4.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
6.2.6.4.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 バージョンに置き換えます。
6.2.7. デプロイの完了
ホステッドクラスターのデプロイは、コントロールプレーンの観点とデータプレーンの観点から監視できます。
6.2.7.1. コントロールプレーンの監視
デプロイの進行中に、次のアーティファクトに関する情報を収集してコントロールプレーンを監視できます。
- HyperShift Operator
-
HostedControlPlane
Pod - ベアメタルホスト
- エージェント
-
InfraEnv
リソース -
HostedCluster
およびNodePool
リソース
手順
コントロールプレーンを監視するには、次のコマンドを入力します。
$ export KUBECONFIG=/root/.kcli/clusters/hub-ipv4/auth/kubeconfig
$ watch "oc get pod -n hypershift;echo;echo;oc get pod -n clusters-hosted-ipv4;echo;echo;oc get bmh -A;echo;echo;oc get agent -A;echo;echo;oc get infraenv -A;echo;echo;oc get hostedcluster -A;echo;echo;oc get nodepool -A;echo;echo;"
6.2.7.2. データプレーンの監視
デプロイの進行中に、次のアーティファクトに関する情報を収集してデータプレーンを監視できます。
- クラスターのバージョン
- ノード (特にノードがクラスターに参加したかどうかについて)
- クラスター Operator
手順
次のコマンドを入力します。
$ oc get secret -n clusters-hosted-ipv4 admin-kubeconfig -o jsonpath='{.data.kubeconfig}' |base64 -d > /root/hc_admin_kubeconfig.yaml
$ export KUBECONFIG=/root/hc_admin_kubeconfig.yaml
$ watch "oc get clusterversion,nodes,co"