検索
サポートコンソール開発者トライアルの開始お問い合わせ

1.7. Hosted Control Plane

download PDF

マルチクラスターエンジン Operator クラスター管理では、スタンドアロンまたは Hosted Control Plane の 2 つの異なるコントロールプレーン設定を使用して、OpenShift Container Platform クラスターをデプロイできます。スタンドアロン設定では、専用の仮想マシンまたは物理マシンを使用して、OpenShift Container Platform のコントロールプレーンをホストします。OpenShift Container Platform の Hosted Control Plane を使用すると、コントロールプレーンごとに専用の物理マシンを必要とせずに、ホスティングクラスター上にコントロールプレーンを Pod として作成できます。

OpenShift Container Platform の Hosted Control Plane は、ベアメタルおよび Red Hat OpenShift Virtualization で、また Amazon Web Services (AWS) の テクノロジープレビュー 機能として利用できます。コントロールプレーンは、OpenShift Container Platform バージョン 4.14 以降でホスティングできます。Hosted Control Plane 機能がデフォルトで有効になりました。

1.7.1. 要件

次の表は、各プラットフォームでサポートされている OpenShift Container Platform のバージョンを示しています。この表では、ホスティング OpenShift Container Platform バージョン は、マルチクラスターエンジン Operator が有効になっている OpenShift Container Platform バージョンを指します。

プラットフォーム

ホスティング OpenShift Container Platform のバージョン

ホステッド OpenShift Container Platform バージョン

ベアメタル

4.14 - 4.15

4.14 - 4.15 のみ

Red Hat OpenShift Virtualization

4.14 - 4.15

4.14 - 4.15 のみ

AWS (テクノロジープレビュー)

4.11 - 4.15

4.14 - 4.15 のみ

注記: Hosted Control Plane の同じプラットフォームで、ハブクラスターとワーカーを実行します。

コントロールプレーンは、単一の namespace に含まれる Pod として実行され、Hosted Control Plane クラスターに関連付けられます。OpenShift Container Platform がこのタイプのホステッドクラスターを作成すると、コントロールプレーンから独立したワーカーノードが作成されます。

プロキシーを使用しており、Pod から Kubernetes API サーバーへのトラフィックでプロキシーを使用しないようにする場合は、デフォルトの Kubernetes API サーバーアドレス 172.20.0.1 を no_proxy リストに追加します。

Hosted Control Plane クラスターには、いくつかの利点があります。

  • 専用コントロールプレーンノードをホストする必要がなくなるため、コストを節約できます。
  • コントロールプレーンとワークロードを分離することで、分離が改善され、変更が必要になる設定エラーが減少します。
  • コントロールプレーンノードのブートストラップの要件をなくすことで、クラスターの作成時間を短縮します。
  • ターンキーデプロイメントまたは完全にカスタマイズされた OpenShift Container Platform プロビジョニングをサポートします。

Hosted Control Plane を使用するには、次のドキュメントから始めてください。

  1. Hosted Control Plane のサイジングに関するガイダンス
  2. Hosted Control Plane コマンドラインインターフェイスのインストール
  3. ホステッドクラスターのワークロードの分散

次に、使用する予定のプラットフォームに関連するドキュメントを参照してください。

追加のネットワーク、Guaranteed CPU、およびノードプールの仮想マシンスケジューリングを設定するには、次のドキュメントを参照してください。

Hosted Control Plane の追加リソースについては、次の OpenShift Container Platform ドキュメントを参照してください。

1.7.2. Hosted Control Plane のサイジングに関するガイダンス

ホステッドクラスターのワークロードやワーカーノード数などの多くの要因が、一定数のコントロールプレーンノード内に収容できるホステッドクラスターの数に影響します。このサイジングガイドを使用して、ホステッドクラスターの容量計画に役立ちます。このガイダンスは、可用性の高い Hosted Control Plane トポロジーを前提としています。ロードベースのサイジングの例は、ベアメタルクラスターで測定されています。クラウドベースのインスタンスには、メモリーサイズなど、さまざまな制限要因が含まれる場合があります。高可用性の Hosted Control Plane トポロジーの詳細は、ホステッドクラスターのワークロードの分散 を参照してください。

次のリソース使用率のサイズ測定をオーバーライドし、メトリクスサービスの監視を無効化できます。詳細は、関連情報 セクションの リソース使用率測定のオーバーライド を参照してください。

OpenShift Container Platform バージョン 4.12.9 以降でテストされた、次の高可用性 Hosted Control Plane 要件を参照してください。

  • 78 pods
  • etcd 用の 3 つの 8 GiB PV
  • 最小仮想 CPU: 約 5.5 コア
  • 最小メモリー: 約 19 GiB

1.7.2.1. Pod の制限

各ノードの maxPods 設定は、コントロールプレーンノードに収容できるホストクラスターの数に影響します。すべてのコントロールプレーンノードの maxPods 値に注意することが重要です。高可用性の Hosted Control Plane ごとに約 75 個の Pod を計画します。

ベアメタルノードの場合、マシンに十分なリソースがある場合でも、Pod 要件を考慮すると、各ノードに約 3 つの Hosted Control Plane が使用されるため、デフォルトで maxPods 設定に 250 が指定されていることが制限要因となる可能性があります。KubeletConfig 値を設定して maxPods 値を 500 に設定すると、Hosted Control Plane の密度が増し、追加のコンピューティングリソースを活用できるようになります。詳細は、OpenShift Container Platform ドキュメントの ノードあたりの最大 Pod 数の設定 を参照してください。

1.7.2.2. 要求ベースのリソース制限

クラスターがホストできる Hosted Control Plane の最大数は、Pod からの Hosted Control Plane CPU およびメモリー要求に基づいて計算されます。

可用性の高い Hosted Control Plane は、5 つの仮想 CPU と 18 GB のメモリーを要求する 78 個の Pod で構成されています。これらのベースライン数値は、クラスターワーカーノードのリソース容量と比較され、Hosted Control Plane の最大数を推定します。

1.7.2.3. ロードベースの制限

クラスターがホストできる Hosted Control Plane の最大数は、Hosted Control Plane の Kubernetes API サーバーにワークロードが配置されているときの Hosted Control Plane Pod の CPU とメモリーの使用率に基づいて計算されます。

ワークロードの増加に伴う Hosted Control Plane リソース使用率を測定するには、次の方法を使用します。

  • KubeVirt プラットフォームを使用し、それぞれ 8 つの仮想 CPU と 32 GiB を使用する 9 つのワーカーを持つホステッドクラスター

  • 次の定義に基づいて、API コントロールプレーンのストレスに重点を置くように設定されたワークロードテストプロファイル:

    • 各 namespace にオブジェクトを作成し、合計 100 の namespace まで拡張しました。
    • オブジェクトの継続的な削除と作成による API のストレスの増加
    • ワークロードの 1 秒あたりのクエリー数 (QPS) とバースト設定を高く設定して、クライアント側のスロットリングを排除します。

負荷が 1000 QPS 増加すると、Hosted Control Plane リソースの使用率は 9 個の仮想 CPU と 2.5 GB のメモリー増加します。

一般的なサイズ設定の目的で、中程度 のホストクラスター負荷である 1000 QPS API レートと、重い ホストクラスター負荷である 2000 QPS API レートを検討してください。

注記: このテストは、予想される API 負荷に基づいてコンピューティングリソースの使用率を高めるための推定係数を提供します。正確な使用率は、クラスターのワークロードのタイプとペースによって異なる場合があります。

表1.7 ロードテーブル
Hosted Control Plane のリソース使用率のスケーリング仮想 CPUメモリー (GiB)

負荷なしのリソース利用

2.9

11.1

1000 QPS でのリソース使用率

9.0

2.5

負荷が 1000 QPS 増加すると、Hosted Control Plane リソースの使用率は 9 個の仮想 CPU と 2.5 GB のメモリー増加します。

一般的なサイジングの目的では、1000 QPS API レートを中程度のホステッドクラスターの負荷、2000 QPS API を高程度のホステッドクラスターの負荷とみなしてください。

次の例は、ワークロードおよび API レート定義の Hosted Control Plane リソースのスケーリングを示しています。

表1.8 API 料金表
QPS (API レート)仮想 CPU の使用量メモリーの使用量 (GiB)

低負荷 (50 QPS 未満)

2.9

11.1

中負荷 (1000 QPS)

11.9

13.6

高負荷 (2000 QPS)

20.9

16.1

Hosted Control Plane のサイジングは、コントロールプレーンの負荷と、大量の API アクティビティー、etcd アクティビティー、またはその両方を引き起こすワークロードに関係します。データベースの実行など、データプレーンの負荷に重点を置くホスト型 Pod ワークロードでは、API レートが高い可能性があります。

1.7.2.4. サイジング計算の例

この例では、次のシナリオに対してサイジングのガイダンスを提供します。

  • hypershift.openshift.io/control-plane ノードとしてラベル付けされたベアメタルワーカー 3 つ
  • maxPods 値を 500 に設定している
  • 負荷ベースの制限に応じて、予想される API レートは中または約 1000 である
表1.9 入力の制限
制限の説明サーバー 1サーバー 2

ワーカーノード上の仮想 CPU 数

64

128

ワーカーノードのメモリー (GiB)

128

256

ワーカーあたりの最大 Pod 数

500

500

コントロールプレーンのホストに使用されるワーカーの数

3

3

最大 QPS ターゲットレート (1 秒あたりの API リクエスト)

1000

1000

表1.10 サイジング計算の例

ワーカーノードのサイズと API レートに基づいた計算値

サーバー 1

サーバー 2

計算の注記

仮想 CPU リクエストに基づくワーカーあたりの最大ホストコントロールプレーン数

12.8

25.6

Hosted Control Plane ごとにワーカー仮想 CPU/5 合計仮想 CPU 要求の数

仮想 CPU 使用率に基づくワーカーあたりの最大 Hosted Control Plane 数

5.4

10.7

仮想 CPU の数 ÷ (2.9 測定されたアイドル状態の仮想 CPU 使用率 + (QPS ターゲットレート ÷ 1000) × 9.0 1000 QPS 増加あたりの測定された仮想 CPU 使用率)

メモリーリクエストに基づくワーカーごとの最大 Hosted Control Plane

7.1

14.2

Hosted Control Plane ごとにワーカーメモリー GiB/18 GiB の合計メモリーリクエスト

メモリー使用量に基づくワーカーあたりの最大 Hosted Control Plane 数

9.4

18.8

ワーカーメモリー GiB ÷ (11.1 測定されたアイドルメモリー使用量 + (QPS ターゲットレート ÷ 1000) × 2.5 1000 QPS 増加あたりの測定されたメモリー使用量)

ノードごとの Pod の制限に基づくワーカーごとの最大 Hosted Control Plane

6.7

6.7

500 maxPod/Hosted Control Plane あたり 75 Pod

前述の最大値の中の最小値

5.4

6.7

 
 

仮想 CPU の制限要因

maxPods の制限要因

 

管理クラスター内の Hosted Control Plane の最大数

16

20

前述の最大 3 つのコントロールプレーンワーカーの最小数。

表1.11 Hosted Control Plane の容量メトリクス

名前

設定

mce_hs_addon_request_based_hcp_capacity_gauge

高可用性 Hosted Control Plane リソース要求に基づいて、クラスターがホストできる Hosted Control Plane の推定最大数。

mce_hs_addon_low_qps_based_hcp_capacity_gauge

すべての Hosted Control Plane がクラスターの Kube API サーバーに約 50 QPS を送信する場合、クラスターがホストできる Hosted Control Plane の推定最大数。

mce_hs_addon_medium_qps_based_hcp_capacity_gauge

すべての Hosted Control Plane がクラスターの Kube API サーバーに約 1000 QPS を送信する場合、クラスターがホストできる Hosted Control Plane の推定最大数。

mce_hs_addon_high_qps_based_hcp_capacity_gauge

すべての Hosted Control Plane がクラスターの Kube API サーバーに約 2000 QPS を送信する場合、クラスターがホストできる Hosted Control Plane の推定最大数。

mce_hs_addon_average_qps_based_hcp_capacity_gauge

Hosted Control Plane の既存の平均 QPS に基づいて、クラスターがホストできる Hosted Control Plane の推定最大数。アクティブな Hosted Control Plane がない場合は、QPS が低くなることが予想されます。

1.7.2.5. 関連情報

1.7.3. リソース使用率測定のオーバーライド

リソース使用率のベースライン測定セットは、クラスターごとに異なる場合があります。詳細は、Hosted Control Plane のサイズガイダンス を参照してください。

クラスターのワークロードの種類とペースに基づいて、リソース使用率の測定をオーバーライドできます。以下の手順を実行します。

  1. 次のコマンドを実行して、ConfigMap リソースを作成します。 

    oc create -f <your-config-map-file.yaml>

    <your-config-map-file.yaml> は hcp-sizing-baseline config map を含む YAML ファイルの名前に置き換えます。

  2. local-cluster namespace に hcp-sizing-baseline config map を作成し、上書きする測定値を指定します。config map は、次の YAML ファイルのようになります。 

    kind: ConfigMap
apiVersion: v1
metadata:
  name: hcp-sizing-baseline
  namespace: local-cluster
data:
  incrementalCPUUsagePer1KQPS: "9.0"
  memoryRequestPerHCP: "18"
  minimumQPSPerHCP: "50.0"

  3. 以下のコマンドを実行して hypershift-addon-agent デプロイメントを削除し、hypershift-addon-agent Pod を再起動します。 

    oc delete deployment hypershift-addon-agent -n open-cluster-management-agent-addon

  4. hypershift-addon-agent Pod ログを監視します。次のコマンドを実行して、オーバーライドされた測定値が config map 内で更新されていることを確認します。 

    oc logs hypershift-addon-agent -n open-cluster-management-agent-addon

    ログは以下の出力のようになります。 

    2024-01-05T19:41:05.392Z	INFO	agent.agent-reconciler	agent/agent.go:793	setting cpuRequestPerHCP to 5
2024-01-05T19:41:05.392Z	INFO	agent.agent-reconciler	agent/agent.go:802	setting memoryRequestPerHCP to 18
2024-01-05T19:53:54.070Z	INFO	agent.agent-reconciler	agent/hcp_capacity_calculation.go:141	The worker nodes have 12.000000 vCPUs
2024-01-05T19:53:54.070Z	INFO	agent.agent-reconciler	agent/hcp_capacity_calculation.go:142	The worker nodes have 49.173369 GB memory

    オーバーライドされた測定値が hcp-sizing-baseline config map で適切に更新されない場合、hypershift-addon-agent Pod ログに次のエラーメッセージが表示されることがあります。 

    2024-01-05T19:53:54.052Z	ERROR	agent.agent-reconciler	agent/agent.go:788	failed to get configmap from the hub. Setting the HCP sizing baseline with default values.	{"error": "configmaps \"hcp-sizing-baseline\" not found"}

1.7.3.1. メトリクスサービスモニタリングの無効化

hypershift-addon マネージドクラスターアドオンを有効にすると、メトリクスサービスモニタリングがデフォルトで設定され、OpenShift Container Platform モニタリングが hypershift-addon からメトリクスを収集できるようになります。次の手順を実行して、メトリクスサービスの監視を無効化できます。

  1. 次のコマンドを実行して、ハブクラスターにログインします。 

    oc login

  2. 次のコマンドを実行して、hypershift-addon-deploy-config アドオンデプロイメント設定仕様を開いて編集します。 

    oc edit addondeploymentconfig hypershift-addon-deploy-config -n multicluster-engine

  3. 次の例に示すように、disableMetrics=true カスタマイズ変数を仕様に追加します。 

    apiVersion: addon.open-cluster-management.io/v1alpha1
kind: AddOnDeploymentConfig
metadata:
  name: hypershift-addon-deploy-config
  namespace: multicluster-engine
spec:
  customizedVariables:
  - name: hcMaxNumber
    value: "80"
  - name: hcThresholdNumber
    value: "60"
  - name: disableMetrics
    value: "true"
  4. 変更を保存します。カスタマイズ変数 disableMetrics=true は、新規および既存の hypershift-addon マネージドクラスターアドオンの両方のメトリクスサービス監視設定を無効にします。

1.7.3.2. 関連情報

1.7.4. Hosted Control Plane コマンドラインインターフェイスのインストール

次の手順を実行して、Hosted Control Plane コマンドラインインターフェイス (hcp) をインストールできます。

  1. OpenShift Container Platform コンソールから、Help icon > Command Line Tools をクリックします。
  2. お使いのプラットフォーム用の Download hcp CLI をクリックします。

  3. 次のコマンドを実行して、ダウンロードしたアーカイブを解凍します。 

    tar xvzf hcp.tar.gz

  4. 次のコマンドを実行して、バイナリーファイルを実行可能にします。 

    chmod +x hcp

  5. 次のコマンドを実行して、バイナリーファイルをパス内のディレクトリーに移動します。 

    sudo mv hcp /usr/local/bin/.

hcp create cluster コマンドを使用して、ホステッドクラスターを作成および管理できるようになりました。使用可能なパラメーターをリストするには、次のコマンドを入力します。 

hcp create cluster <platform> --help 1
1
サポートされているプラットフォームは、aws、agent、および kubevirt です。

1.7.4.1. CLI を使用した Hosted Control Plane コマンドラインインターフェイスのインストール

次の手順を実行すると、CLI を使用して Hosted Control Plane コマンドラインインターフェイス (hcp) をインストールできます。

  1. 次のコマンドを実行して、hcp バイナリーをダウンロードするための URL を取得します。 

    oc get ConsoleCLIDownload hcp-cli-download -o json | jq -r ".spec"

  2. 次のコマンドを実行して hcp バイナリーをダウンロードします。 

    wget <hcp_cli_download_url> 1
    1
    hcp_cli_download_url は、前の手順で取得した URL に置き換えます。

  3. 次のコマンドを実行して、ダウンロードしたアーカイブを解凍します。 

    tar xvzf hcp.tar.gz

  4. 次のコマンドを実行して、バイナリーファイルを実行可能にします。 

    chmod +x hcp

  5. 次のコマンドを実行して、バイナリーファイルをパス内のディレクトリーに移動します。 

    sudo mv hcp /usr/local/bin/.

1.7.4.2. コンテンツゲートウェイを使用した Hosted Control Plane コマンドラインインターフェイスのインストール

コンテンツゲートウェイを使用して、Hosted Control Plane コマンドラインインターフェイス (hcp) をインストールできます。以下の手順を実行します。

  1. コンテンツゲートウェイ に移動し、hcp バイナリーをダウンロードします。

  2. 次のコマンドを実行して、ダウンロードしたアーカイブを解凍します。 

    tar xvzf hcp.tar.gz

  3. 次のコマンドを実行して、バイナリーファイルを実行可能にします。 

    chmod +x hcp

  4. 次のコマンドを実行して、バイナリーファイルをパス内のディレクトリーに移動します。 

    sudo mv hcp /usr/local/bin/.

hcp create cluster コマンドを使用して、ホステッドクラスターを作成および管理できるようになりました。使用可能なパラメーターをリストするには、次のコマンドを入力します。 

hcp create cluster <platform> --help 1
1
サポートされているプラットフォームは、aws、agent、および kubevirt です。

1.7.5. ホステッドクラスターのワークロードの分散

OpenShift Container Platform の Hosted Control Plane を使い始める前に、ホスト型クラスター Pod をインフラストラクチャーノードにスケジュールするためにノードにラベルを付ける必要があります。

ノードのラベル付けにより、次の機能が保証されます。

  • 高可用性と適切なワークロードのデプロイメント。たとえば、node-role.kubernetes.io/infra ラベルを設定して、OpenShift Container Platform サブスクリプションに control-plane ワークロード数が割り当てられないようにできます。
  • コントロールプレーンのワークロードを管理クラスター内の他のワークロードから分離します。

重要: ワークロードには管理クラスターを使用しないでください。ワークロードは、コントロールプレーンが実行されるノード上で実行してはなりません。

1.7.5.1. 管理クラスターノードのラベルとテイント

管理クラスター管理者は、管理クラスターノードで次のラベルとテイントを使用して、コントロールプレーンのワークロードをスケジュールします。

  • hypershift.openshift.io/control-plane: true: このラベルとテイントを使用して、Hosted Control Plane ワークロードの実行専用にノードを割り当てます。true を設定すると、コントロールプレーンノードを他のコンポーネントと共有することがなくなります。
  • hypershift.openshift.io/cluster: <hosted-control-plane-namespace>: ノードを単一のホストされたクラスター専用にする場合は、このラベルとテイントを使用します。

コントロールプレーン Pod をホストするノードに以下のラベルを適用します。

  • node-role.kubernetes.io/infra: このラベルを使用して、サブスクリプションにコントロールプレーンワークロード数が割り当てられないようにします。
  • topology.kubernetes.io/zone: このラベルを管理クラスターノードで使用して、障害ドメイン全体に高可用性クラスターをデプロイします。ゾーンは、ゾーンが設定されているノードの場所、ラック名、またはホスト名である場合があります。

各ラックを管理クラスターノードのアベイラビリティーゾーンとして使用するには、次のコマンドを入力します。 

oc label node/<management_node1_name> node/<management_node2_name> topology.kubernetes.io/zone=<rack_name>

ホステッドクラスターの Pod には許容範囲があり、スケジューラーはアフィニティールールを使用して Pod をスケジュールします。スケジューラーは、hypershift.openshift.io/control-plane および hypershift.openshift.io/cluster: <hosted_control_plane_namespace> でラベル付けされたノードへの Pod のスケジューリングを優先します。

ControllerAvailabilityPolicy オプションには、HighlyAvailable を使用します。これは、Hosted Control Plane のコマンドラインインターフェイス (hcp) がデプロイメントするデフォルト値です。このオプションを使用する場合は、topology.kubernetes.io/zone をトポロジーキーとして設定することで、さまざまな障害ドメインにわたるホステッドクラスター内のデプロイメントごとに Pod をスケジュールできます。高可用性ではないコントロールプレーンはサポートされていません。

1.7.5.2. ホステッドクラスターのノードのラベル付け

重要: Hosted Control Plane をデプロイする前に、ノードにラベルを追加する必要があります。

ホストされたクラスターで実行している Pod をインフラストラクチャーノードにスケジュールするには、HostedCluster カスタムリソース (CR) に role.kubernetes.io/infra: "" ラベルを追加します。以下の例を参照してください。 

  spec:
    nodeSelector:
      role.kubernetes.io/infra: ""

1.7.5.3. 優先クラス

4 つの組み込み優先クラスは、ホステッドクラスター Pod の優先順位とプリエンプションに影響を与えます。管理クラスター内に Pod は、次の上位から下位の順序で作成できます。

  • hypershift-operator: HyperShift Operator Pod。
  • hypershift-etcd: etcd 用の Pod。
  • hypershift-api-critical: API 呼び出しとリソース許可が成功するために必要な Pod。この優先クラスには、kube-apiserver (集約された API サーバー) や Web フックなどの Pod が含まれます。
  • hypershift-control-plane : API クリティカルではないものの、クラスターバージョンの Operator など、高い優先順位が必要なコントロールプレーン内の Pod。

1.7.5.4. 関連情報

Hosted Control Plane の詳細は、次のトピックを参照してください。

1.7.6. AWS での Hosted Control Plane クラスターの設定 (テクノロジープレビュー)

Hosted Control Plane を設定するには、ホスティングクラスターとホステッドクラスターが必要です。hypershift-addon マネージドクラスターアドオンを使用して既存のマネージドクラスターに HyperShift Operator をデプロイすることにより、そのクラスターをホスティングクラスターとして有効にして、ホステッドクラスターを作成し始めることができます。hypershift-addon マネージドクラスターアドオンは、マルチクラスターエンジン Operator 2.5 および Red Hat Advanced Cluster Management 2.10 ハブクラスターの local-cluster マネージドクラスターに対してデフォルトで有効になっています。

ホストされたクラスター は、ホスティングクラスターでホストされる API エンドポイントとコントロールプレーンを含む OpenShift Container Platform クラスターです。ホステッドクラスターには、コントロールプレーンとそれに対応するデータプレーンが含まれます。マルチクラスターエンジンの Operator コンソールまたは Hosted Control Plane のコマンドラインインターフェイス hcp を使用して、ホステッドクラスターを作成できます。ホステッドクラスターは、マネージドクラスターとして自動的にインポートされます。この自動インポート機能を無効にする場合は、マルチクラスターエンジン Operator へのホストクラスターの自動インポートの無効化 を参照してください。

重要:

  • 各ホステッドクラスターに、クラスター全体で一意の名前が必要です。マルチクラスターエンジン Operator によってホストクラスターを管理するには、ホストクラスター名を既存のマネージドクラスターと同じにすることはできません。
  • ホステッドクラスター名として clusters を使用しないでください。
  • Hosted Control Plane の同じプラットフォームで、ハブクラスターとワーカーを実行します。
  • ホステッドクラスターは、マルチクラスターエンジンの operator 管理クラスターの namespace には作成できません。

1.7.6.1. 前提条件

ホスティングクラスターを設定するには、次の前提条件を満たす必要があります。

  • OpenShift Container Platform クラスターにインストールされた Kubernetes Operator 2.5 以降のマルチクラスターエンジン。マルチクラスターエンジン Operator は、Red Hat Advanced Cluster Management をインストールすると自動的にインストールされます。マルチクラスターエンジン Operator は、Red Hat Advanced Cluster Management を使用せずに OpenShift Container Platform OperatorHub から Operator としてインストールすることもできます。

  • マルチクラスターエンジン Operator には、少なくとも 1 つのマネージド OpenShift Container Platform クラスターが必要です。local-cluster は、マルチクラスターエンジン Operator 2.5 以降で自動的にインポートされます。local-cluster の詳細については、詳細設定 を参照してください。次のコマンドを実行して、ハブクラスターの状態を確認できます。 

    oc get managedclusters local-cluster
  • AWS コマンドラインインターフェイス
  • Hosted Control Plane コマンドラインインターフェイス

Hosted Control Plane の関連資料については、次のドキュメントを参照してください。

1.7.6.2. Amazon Web Services S3 バケットと S3 OIDC シークレットの作成

AWS でホステッドクラスターを作成および管理する予定の場合は、次の手順を実行します。

  1. クラスターの OIDC 検出ドキュメントをホストするためのパブリックアクセスを持つ S3 バケットを作成します。

    • us-east-1 リージョンにバケットを作成するには、次のコードを入力します。 

      aws s3api create-bucket --bucket <your-bucket-name>
aws s3api delete-public-access-block --bucket <your-bucket-name>
echo '{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::<your-bucket-name>/*"
        }
    ]
}' | envsubst > policy.json
aws s3api put-bucket-policy --bucket <your-bucket-name> --policy file://policy.json
    • us-east-1 リージョン以外のリージョンにバケットを作成するには、次のコードを入力します。 
    aws s3api create-bucket --bucket <your-bucket-name> \
  --create-bucket-configuration LocationConstraint=<region> \
  --region <region>
aws s3api delete-public-access-block --bucket <your-bucket-name>
echo '{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::<your-bucket-name>/*"
        }
    ]
}' | envsubst > policy.json
aws s3api put-bucket-policy --bucket <your-bucket-name> --policy file://policy.json
  2. HyperShift Operator 用に hypershift-operator-oidc-provider-s3-credentials という名前の OIDC S3 シークレットを作成します。
  3. シークレットを local-cluster namespace に保存します。

  4. 次の表を参照して、シークレットに次のフィールドが含まれていることを確認します。

    フィールド名設定

    bucket

    ホステッドクラスターの OIDC 検出ドキュメントをホストするためのパブリックアクセスを備えた S3 バケットが含まれています。

    credentials

    バケットにアクセスできる default プロファイルの認証情報を含むファイルへの参照。デフォルトでは、HyperShift は default プロファイルのみを使用して バケット を操作します。

    region

    S3 バケットのリージョンを指定します。

    次の例は、サンプルの AWS シークレットテンプレートを示しています。 

    oc create secret generic hypershift-operator-oidc-provider-s3-credentials --from-file=credentials=<path>/.aws/credentials --from-literal=bucket=<s3-bucket-for-hypershift> --from-literal=region=<region> -n local-cluster

    注記: シークレットのリカバリーバックアップは自動的に有効になりません。以下のコマンドを実行して、障害復旧用に hypershift-operator-oidc-provider-s3-credentials シークレットのバックアップを有効にするラベルを追加します。 

    oc label secret hypershift-operator-oidc-provider-s3-credentials -n local-cluster cluster.open-cluster-management.io/backup=true

1.7.6.3. ルーティング可能なパブリックゾーンの作成

ゲストクラスター内のアプリケーションにアクセスするには、パブリックゾーンがルーティング可能である必要があります。パブリックゾーンが存在する場合は、この手順を省略します。省力しない場合は、パブリックゾーンが既存の機能に影響を及ぼします。

次のコマンドを実行して、クラスター DNS レコードのパブリックゾーンを作成します。 

aws route53 create-hosted-zone --name <your-basedomain> --caller-reference $(whoami)-$(date --rfc-3339=date)

your-basedomain をベースドメインに置き換えます (例: www.example.com)。

1.7.6.4. 外部 DNS の有効化

Hosted Control Plane では、コントロールプレーンとデータプレーンが分離されています。DNS は、次の 2 つの独立した領域で設定できます。

  • 次のドメインなど、ホステッドクラスター内のワークロードの Ingress: *.apps.service-consumer-domain.com
  • サービスプロバイダードメインを介した API または OAUTH エンドポイントなど、管理クラスター内のサービスエンドポイントの受信: *.service-provider-domain.com

hostedCluster.spec.dns の入力は、ホストされたクラスター内のワークロードの Ingress を管理します。hostedCluster.spec.services.servicePublishingStrategy.route.hostname の入力は、管理クラスター内のサービスエンドポイントの Ingress を決定します。

外部 DNS は、LoadBalancer または Route の公開タイプを指定し、その公開タイプのホスト名を提供するホステッドクラスター Services の名前レコードを作成します。Private または PublicAndPrivate エンドポイントアクセスタイプを持つホステッドクラスターの場合、APIServer サービスと OAuth サービスのみがホスト名をサポートします。Private ホストクラスターの場合、DNS レコードは VPC 内の仮想プライベートクラウド (VPC) エンドポイントのプライベート IP アドレスに解決されます。

Hosted Control Plane は、次のサービスを公開します。

  • APIServer
  • OAuthServer
  • Konnectivity
  • Ignition
  • OVNSbDb
  • OIDC

これらのサービスは、HostedCluster 仕様の servicePublishingStrategy フィールドを使用して公開できます。デフォルトでは、servicePublishingStrategy の LoadBalancer および Route タイプの場合、次のいずれかの方法でサービスを公開できます。

  • LoadBalancer タイプの Service ステータスにあるロードバランサーのホスト名を使用する
  • Route リソースの status.host フィールドを使用する方法

ただし、Hosted Control Plane をマネージドサービスコンテキストにデプロイメントする場合、これらの方法では、基盤となる管理クラスターの Ingress サブドメインが公開され、管理クラスターのライフサイクルとディザスターリカバリーのオプションが制限される可能性があります。

DNS 間接化が LoadBalancer および Route 公開タイプに階層化されている場合、マネージドサービスオペレーターは、サービスレベルドメインを使用してすべてのパブリックホステッドクラスターサービスを公開できます。このアーキテクチャーでは、DNS 名を新しい LoadBalancer または Route に再マッピングできますが、管理クラスターの Ingress ドメインは公開されません。Hosted Control Plane は、外部 DNS を使用して間接層を実現します。

管理クラスターの hypershift namespace に HyperShift Operator と一緒に external-dns をデプロイできます。外部 DNS は、external-dns.alpha.kubernetes.io/hostname アノテーションを持つ Services または Routes を監視します。このアノテーションは、レコードなどの Service、または CNAME レコードなどの Route を指す DNS レコードを作成するために使用されます。

外部 DNS はクラウド環境でのみ使用できます。その他の環境では、DNS とサービスを手動で設定する必要があります。

外部 DNS の詳細は、外部 DNS を参照してください。

1.7.6.4.1. 前提条件

Hosted Control Plane の外部 DNS を設定する前に、次の前提条件を満たす必要があります。

  • 外部のパブリックドメインを作成している
  • AWS Route53 Management コンソールにアクセスできる。
1.7.6.4.2. Hosted Control Plane の外部 DNS の設定

Hosted Control Plane クラスターをサービスレベル DNS (外部 DNS) でプロビジョニングする場合は、次の手順を実行します。

  1. HyperShift Operator の AWS 認証情報シークレットを作成し、local-cluster namespace で hypershift-operator-external-dns-credentials という名前を付けます。

  2. 次の表を参照して、シークレットに必須フィールドが含まれていることを確認してください。

    フィールド名設定任意または必須

    provider

    サービスレベル DNS ゾーンを管理する DNS プロバイダー。

    必須

    domain-filter

    サービスレベルドメイン。

    必須

    credentials

    すべての外部 DNS タイプをサポートする認証情報ファイル。

    AWS キーを使用する場合はオプション

    aws-access-key-id

    認証情報アクセスキー ID。

    AWS DNS サービスを使用する場合はオプション

    aws-secret-access-key

    認証情報アクセスキーのシークレット。

    AWS DNS サービスを使用する場合はオプション

    次の例は、サンプルの hypershift-operator-external-dns-credentials シークレットテンプレートを示しています。 

    oc create secret generic hypershift-operator-external-dns-credentials --from-literal=provider=aws --from-literal=domain-filter=<domain_name> --from-file=credentials=<path_to_aws_credentials_file> -n local-cluster

    注記: シークレットのリカバリーバックアップは自動的に有効になりません。障害復旧のためにシークレットをバックアップするには、次のコマンドを入力して hypershift-Operator-external-dns-credentials を追加します。 

    oc label secret hypershift-operator-external-dns-credentials -n local-cluster cluster.open-cluster-management.io/backup=""
1.7.6.4.3. パブリック DNS ホストゾーンの作成

外部 DNS Operator は、パブリック DNS ホストゾーンを使用してパブリックホストクラスターを作成します。

外部 DNS ドメインフィルターとして使用するパブリック DNS ホストゾーンを作成できます。AWS Route 53 管理コンソールで次の手順を実行します。

  1. Route 53 管理コンソールで、Create hosted zone をクリックします。
  2. Hosted zone configuration ページでドメイン名を入力し、タイプとして Publish hosted zone が選択されていることを確認し、Create hosted zone をクリックします。
  3. ゾーンが作成されたら、Records タブの Value/Route traffic to 列の値をメモします。
  4. メインドメインで、DNS 要求を委任ゾーンにリダイレクトするための NS レコードを作成します。Value フィールドに、前の手順でメモした値を入力します。
  5. Create records をクリックします。

  6. 新しいサブゾーンにテストエントリーを作成し、次の例のような dig コマンドでテストすることにより、DNS ホストゾーンが機能していることを確認します。 

    dig +short test.user-dest-public.aws.kerberos.com
192.168.1.1

  7. LoadBalancer および Route サービスのホスト名を設定するホストクラスターを作成するには、次のコマンドを入力します。 

    hcp create cluster aws --name=<hosted_cluster_name> --endpoint-access=PublicAndPrivate --external-dns-domain=<public_hosted_zone> ...

    <public_hosted_zone> は、作成したパブリックホストゾーンに置き換えます。

この例は、ホステッドクラスターの結果として生じる services ブロックを示しています。 

  platform:
    aws:
      endpointAccess: PublicAndPrivate
...
  services:
  - service: APIServer
    servicePublishingStrategy:
      route:
        hostname: api-example.service-provider-domain.com
      type: Route
  - service: OAuthServer
    servicePublishingStrategy:
      route:
        hostname: oauth-example.service-provider-domain.com
      type: Route
  - service: Konnectivity
    servicePublishingStrategy:
      type: Route
  - service: Ignition
    servicePublishingStrategy:
      type: Route

Control Plane Operator は、Services と Routes リソースを作成し、external-dns.alpha.kubernetes.io/hostname のアノテーションを付けます。Services と Routes の場合、Control Plane Operator は、サービスエンドポイントの servicePublishingStrategy フィールドの hostname パラメーターの値を使用します。DNS レコードを作成するには、external-dns デプロイメントなどのメカニズムを使用できます。

サービスレベルの DNS 間接化をパブリックサービスにのみ設定できます。プライベートサービスは hypershift.local プライベートゾーンを使用するため、hostname を設定できません。

次の表は、サービスとエンドポイントの組み合わせに対して hostname を設定することが有効な場合を示しています。

サービスPublicPublicAndPrivatePrivate

APIServer

可能

可能

N

OAuthServer

可能

可能

N

Konnectivity

可能

N

N

Ignition

可能

N

N

1.7.6.4.4. コマンドラインインターフェイスと外部 DNS を使用したクラスターのデプロイ

PublicAndPrivate または Public 公開ストラテジーを使用してホストされたクラスターを作成するには、管理クラスターで次のアーティファクトが設定されている必要があります。

  • パブリック DNS ホストゾーン
  • 外部 DNS Operator
  • HyperShift Operator

コマンドラインインターフェイスを使用してホストされたクラスターをデプロイするには、次の手順を実行します。

  1. 管理クラスターにアクセスするには、次のコマンドを入力します。 

    export KUBECONFIG=<path_to_management_cluster_kubeconfig>

  2. 次のコマンドを入力して、外部 DNS Operator が実行されていることを確認します。 

    oc get pod -n hypershift -lapp=external-dns

    以下の出力例を参照してください。 

    NAME                            READY   STATUS    RESTARTS   AGE
external-dns-7c89788c69-rn8gp   1/1     Running   0          40s

  3. 外部 DNS を使用してホストされたクラスターを作成するには、次のコマンドを入力します。 

    hypershift create cluster aws \
    --aws-creds <path_to_aws_credentials_file> \ 1
    --instance-type <instance_type> \ 2
    --region <region> \ 3
    --auto-repair \
    --generate-ssh \
    --name <hosted_cluster_name> \ 4
    --namespace clusters \
    --base-domain <service_consumer_domain> \ 5
    --node-pool-replicas <node_replica_count> \ 6
    --pull-secret <path_to_your_pull_secret> \ 7
    --release-image quay.io/openshift-release-dev/ocp-release:<ocp_release_image> \ 8
    --external-dns-domain=<service_provider_domain> \ 9
    --endpoint-access=PublicAndPrivate 10
    1
    AWS 認証情報ファイルへのパスを指定します (例: /user/name/.aws/credentials)。
    2
    インスタンスタイプを指定します (例: m6i.xlarge)。
    3
    AWS リージョンを指定します (例: us-east-1)。
    4
    ホストされたクラスター名を指定します (例: my-external-aws)。
    5
    サービスコンシューマーが所有するパブリックホストゾーンを指定します (例: service-consumer-domain.com)。
    6
    ノードのレプリカ数を指定します (例: 2)。
    7
    プルシークレットファイルへのパスを指定します。
    8
    使用するサポートされている OpenShift Container Platform のバージョンを指定します (例: 4.14.0-x86_64)。
    9
    サービスプロバイダーが所有するパブリックホストゾーンを指定します (例: service-provider-domain.com)。
    10
    PublicAndPrivate として設定します。外部 DNS は、Public または PublicAndPrivate 設定でのみ使用できます。

1.7.6.6. ホステッドクラスターのディザスタリカバリー

Hosted Control Plane は、マルチクラスターエンジン Operator ハブクラスター上で実行されます。データプレーンは、選択した別のプラットフォーム上で実行されます。マルチクラスターエンジンの operator ハブクラスターを災害から復旧する場合、ホストされているコントロールプレーンも復旧する必要がある場合があります。

Hosted Control Plane クラスターをバックアップし、別のクラスターに復元する方法は、AWS リージョン内のホステッドクラスターのディザスターリカバリー を参照してください。

重要: ホステッドクラスターの障害復旧は AWS でのみ利用できます。

1.7.6.7. ホステッドクラスターの AWS へのデプロイ

Hosted Control Plane マンドラインインターフェイス (hcp) を設定し、local-cluster ホスティングクラスターとして有効にしたら、次の手順を実行して、AWS にホステッドクラスターをデプロイできます。プライベートホストクラスターをデプロイするには、AWS でのプライベートホストクラスターのデプロイ を参照してください。

  1. 各変数の説明を表示するには、次のコマンドを実行します。 

    hcp create cluster aws --help
  2. ハブクラスターにログインしていることを確認します。

  3. 次のコマンドを実行して、ホステッドクラスターを作成します。 

    hcp create cluster aws \
    --name <hosted_cluster_name> \ 1
    --infra-id <infra_id> \ 2
    --base-domain <basedomain> \ 3
    --aws-creds <path_to_aws_creds> \ 4
    --pull-secret <path_to_pull_secret> \ 5
    --region <region> \ 6
    --generate-ssh \
    --node-pool-replicas <node_pool_replica_count> \ 7
    --namespace <hosted_cluster_namespace> 8
1
ホステッドクラスターの名前を指定します (例: example)。<hosted_cluster_name> と <infra_id> の値が同じであることを確認してください。そうしないと、クラスターが Kubernetes Operator コンソールのマルチクラスターエンジンに正しく表示されない可能性があります。
2
インフラストラクチャーの名前を指定します (例: clc-name-hs1)。
3
ベースドメインを指定します (例: dev09.red-chesterfield.com)。
4
AWS 認証情報ファイルへのパスを指定します (例: /user/name/.aws/credentials)。
5
プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
6
AWS リージョン名を指定します (例: us-east-1)。
7
ノードプールのレプリカ数を指定します (例: 2)。
8
ホストされたクラスターの namespace を指定します (例: clusters)。

注記: デフォルトでは、HostedCluster と NodePool のすべてのカスタムリソースが clusters namespace に作成されます。--namespace <namespace> パラメーターを指定すると、選択した namespace に HostedCluster および NodePool カスタムリソースが作成されます。

  1. 以下のコマンドを実行して、ホステッドクラスターのステータスを確認することもできます。 

    oc get hostedclusters -n <hosted_cluster_namespace>
  2. 以下のコマンドを実行してノードプールを確認できます。 
oc get nodepools --namespace <hosted_cluster_namespace>

1.7.6.8. AWS 上の複数のゾーンにホステッドクラスターを作成する

次のコマンドを入力して、パブリックゾーンのベースドメインを指定してクラスターを作成します。 

hcp create cluster aws \
--name <hosted-cluster-name> \ 1
--node-pool-replicas=<node-pool-replica-count> \ 2
--base-domain <basedomain> \ 3
--pull-secret <path-to-pull-secret> \ 4
--aws-creds <path-to-aws-credentials> \ 5
--region <region> \ 6
--zones <zones> 7
1
ホストされているクラスターの名前を指定します (例: example)。
2
ノードプールのレプリカ数を指定します (例: 2)。
3
ベースドメインを指定します (例: example.com)。
4
プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
5
AWS 認証情報ファイルへのパスを指定します (例: /user/name/.aws/credentials)。
6
AWS リージョン名を指定します (例: us-east-1)。
7
AWS リージョン内のアベイラビリティーゾーンを指定します (例: us-east-1a、us-east-1b)。

指定したゾーンごとに、次のインフラストラクチャーが作成されます。

  • パブリックサブネット
  • プライベートサブネット
  • NAT ゲートウェイ
  • プライベートルートテーブル (パブリックルートテーブルはパブリックサブネット間で共有されます)

ゾーンごとに 1 つの NodePool リソースが作成されます。ノードプール名の末尾にはゾーン名が付けられます。ゾーンのプライベートサブネットは spec.platform.aws.subnet.id に設定されます。

1.7.6.8.1. AWS でホストされたクラスターを作成するための認証情報の提供

hcp create cluster aws コマンドを使用してホステッドクラスターを作成する場合は、クラスターのインフラストラクチャーリソースを作成する権限が割り当てられた AWS アカウント認証情報を指定する必要があります。インフラストラクチャーリソースの例としては、VPC、サブネット、NAT ゲートウェイなどがあります。AWS 認証情報は、--aws-creds フラグを使用する方法と、マルチクラスターエンジン Operator からの AWS クラウドプロバイダーのシークレットを使用する方法の 2 つの方法で指定できます。

1.7.6.8.1.1. --aws-creds フラグを使用した認証情報の指定

--aws-creds フラグを使用して認証情報を指定する場合は、そのフラグを AWS 認証情報ファイルパスの値に使用します。

以下の例を参照してください。 

hcp create cluster aws \
--name <hosted-cluster-name> \ 1
--node-pool-replicas=<node-pool-replica-count> \ 2
--base-domain <basedomain> \ 3
--pull-secret <path-to-pull-secret> \ 4
--aws-creds <path-to-aws-credentials> \ 5
--region <region> 6
1
ホストされているクラスターの名前を指定します (例: example)。
2
ノードプールのレプリカ数を指定します (例: 2)。
3
ベースドメインを指定します (例: example.com)。
4
プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
5
AWS 認証情報ファイルへのパスを指定します (例: /user/name/.aws/credentials)。
6
AWS リージョン名を指定します (例: us-east-1)。
1.7.6.8.1.2. AWS クラウドプロバイダーシークレットを使用した認証情報の提供

シークレットには、SSH キー、プルシークレット、ベースドメイン、AWS 認証情報が含まれます。したがって、--secret-creds フラグを指定した hcp create cluster aws コマンドを使用して、AWS 認証情報を提供できます。以下の例を参照してください。 

hcp create cluster aws \
--name <hosted-cluster-name> \ 1
--region <region> \ 2
--namespace <hosted-cluster-namespace> \ 3
--secret-creds <my-aws-cred> 4
1
ホストされているクラスターの名前を指定します (例: example)。
2
AWS リージョン名を指定します (例: us-east-1)。
3
シークレットがデフォルトの clusters namespace にない場合は、ホストされているクラスター namespace を指定します。
4
AWS シークレット名を指定します (例: my-aws-cred)。

このシークレットを使用すると、以下のフラグはオプションです。これらのフラグを --secret-creds フラグと合わせて指定すると、クラウドプロバイダーのシークレットの値よりも優先されます。

  • --aws-creds
  • --base-domain
  • --pull-secret
  • --ssh-key
  1. {mce-shortF} コンソールを使用してシークレットを作成するには、ナビゲーションメニューから Credentials を選択し、コンソールで認証情報の作成手順に従います。

  2. コマンドラインでシークレットを作成するには、次のコマンドを入力します。 

    $ oc create secret generic <my-secret> -n <namespace> --from-literal=baseDomain=<your-basedomain> --from-literal=aws_access_key_id=<your-aws-access-key> --from-literal=aws_secret_access_key=<your-aws-secret-key> --from-literal=pullSecret='{"auths":{"cloud.openshift.com":{"auth":"<auth>", "email":"<your-email>"}, "quay.io":{"auth":"<auth>", "email":"<your-email>"} } }' --from-literal=ssh-publickey=<your-ssh-publickey> --from-literal=ssh-privatekey=<your-ssh-privatekey>

    シークレットの形式は次のとおりです。 

    apiVersion: v1
metadata:
  name: my-aws-cred 1
  namespace: clusters 2
type: Opaque
kind: Secret
stringData:
  ssh-publickey:          # Value
  ssh-privatekey:         # Value
  pullSecret:             # Value, required
  baseDomain:             # Value, required
  aws_secret_access_key:  # Value, required
  aws_access_key_id:      # Value, required
1.7.6.8.2. 関連情報

ホステッドクラスターに AWS Elastic File Service (EFS) CSI Driver Operator をインストールする手順は、セキュリティートークンサービスを使用した AWS EFS CSI Driver Operator の設定 を参照してください。

1.7.6.9. ARM64 OpenShift Container Platform クラスターで Hosted Control Plane を有効にする (テクノロジープレビュー)

ARM64 でホストされるコントロールプレーンを有効にして、管理クラスター環境で OpenShift Container Platform ARM64 データプレーンと連携できるようにすることができます。この機能は、AWS 上の Hosted Control Plane でのみ利用できます。

1.7.6.9.1. 前提条件

64 ビット ARM インフラストラクチャーにインストールされた OpenShift Container Platform クラスターが必要です。詳細は、OpenShift クラスターの作成: AWS (ARM) を参照してください。

1.7.6.9.2. ARM64 OpenShift Container Platform クラスター上でホステッドクラスターを実行する

ARM64 OpenShift Container Platform クラスター上でホステッドクラスターを実行するには、次の手順を完了します。

  1. デフォルトのリリースイメージをマルチアーキテクチャーリリースイメージでオーバーライドするホステッドクラスターを作成します。

    たとえば、Hosted Control Plane コマンドラインインターフェイス (hcp) を介して、次のコマンドを入力します。クラスター名、ノードプールレプリカ、ベースドメイン、プルシークレット、AWS 認証情報、およびリージョンを実際の情報に置き換えます。 

    hcp create cluster aws \
--name $CLUSTER_NAME \
--node-pool-replicas=$NODEPOOL_REPLICAS \
--base-domain $BASE_DOMAIN \
--pull-secret $PULL_SECRET \
--aws-creds $AWS_CREDS \
--region $REGION \
--release-image quay.io/openshift-release-dev/ocp-release:4.13.0-rc.0-multi

    この例では、--node-pool-replicas フラグを使用してデフォルトの NodePool オブジェクトを追加します。

  2. 64 ビット x_86 NodePool オブジェクトをホステッドクラスターに追加します。

    たとえば、Hosted Control Plane (hcp) コマンドラインインターフェイスを使用して、次のコマンドを入力します。クラスター名、ノードプール名、ノードプールレプリカを実際の情報に置き換えるよう注意してください。 

    hcp create nodepool aws \
--cluster-name $CLUSTER_NAME \
--name $NODEPOOL_NAME \
--node-count=$NODEPOOL_REPLICAS
1.7.6.9.3. AWS がホストするクラスターでの ARM NodePool オブジェクトの作成

同じ Hosted Control Plane から、64 ビット ARM および AMD64 上のアプリケーションワークロード (NodePool オブジェクト) をスケジュールできます。これを行うには、NodePool 仕様で Arch フィールドを定義し、NodePool オブジェクトに必要なプロセッサーアーキテクチャーを設定します。arch フィールドの有効な値は次のとおりです。

  • arm64
  • amd64

arch フィールドの値を指定しない場合は、デフォルトで amd64 値が使用されます。

AWS 上のホストされたクラスター上に ARM NodePool オブジェクトを作成するには、次の手順を実行します。

  1. HostedCluster カスタムリソースで使用するマルチアーキテクチャーイメージがあることを確認してください。マルチアーキテクチャーの夜間イメージには https://multi.ocp.releases.ci.openshift.org/ でアクセスできます。

    マルチアーキテクチャーの夜間イメージは次の例のようになります。 

    % oc image info quay.io/openshift-release-dev/ocp-release-nightly@sha256:9b992c71f77501678c091e3dc77c7be066816562efe3d352be18128b8e8fce94 -a ~/pull-secrets.json

error: the image is a manifest list and contains multiple images - use --filter-by-os to select from:

  OS            DIGEST
  linux/amd64   sha256:c9dc4d07788ebc384a3d399a0e17f80b62a282b2513062a13ea702a811794a60
  linux/ppc64le sha256:c59c99d6ff1fe7b85790e24166cfc448a3c2ac3ef3422fce3c7259e48d2c9aab
  linux/s390x   sha256:07fcd16d5bee95196479b1e6b5b3b8064dd5359dac75e3d81f0bd4be6b8fe208
  linux/arm64   sha256:1d93a6beccc83e2a4c56ecfc37e921fe73d8964247c1a3ec34c4d66f175d9b3d

  2. Hosted Control Plane のコマンドラインインターフェイス (hcp) で次のコマンドを入力して、NodePool オブジェクトをレンダリングします。 

    hcp create nodepool aws --cluster-name $CLUSTER_NAME --name $ARM64_NODEPOOL_NAME --node-count=$NODEPOOL_REPLICAS --render > arm_nodepool_spec.yml

    このコマンドは、次の例に示すように、NodePool オブジェクトの CPU アーキテクチャーを指定する YAML ファイルを作成します。 

    apiVersion: hypershift.openshift.io/v1beta1
kind: NodePool
metadata:
  creationTimestamp: null
  name: hypershift-arm-us-east-1a
  namespace: clusters
spec:
  arch: amd64
  clusterName: hypershift-arm
  management:
    autoRepair: false
    upgradeType: Replace
  nodeDrainTimeout: 0s
  platform:
    aws:
      instanceProfile: hypershift-arm-2m289-worker
      instanceType: m5.large
      rootVolume:
        size: 120
        type: gp3
      securityGroups:
      - id: sg-064ea63968d258493
      subnet:
        id: subnet-02c74cf1cf1e7413f
    type: AWS
  release:
    image: quay.io/openshift-release-dev/ocp-release-nightly@sha256:390a33cebc940912a201a35ca03927ae5b058fbdae9626f7f4679786cab4fb1c
  replicas: 3
status:
  replicas: 0

  3. 次のコマンドを入力して、YAML ファイルの arch 値と instanceType 値を変更します。このコマンドでは、ARM インスタンスタイプは m6g.large ですが、どの ARM インスタンスタイプでも機能します。 

    sed 's/arch: amd64/arch: arm64/g; s/instanceType: m5.large/instanceType: m6g.large/g' arm_nodepool_spec.yml > temp.yml && mv temp.yml arm_nodepool_spec.yml

  4. 次のコマンドを入力して、レンダリングされた YAML ファイルをホステッドクラスターに適用します。 

    oc apply -f arm_nodepool_spec.yml

1.7.6.10. ホステッドクラスターへのアクセス

ホステッドクラスターにアクセスするには、kubeconfig ファイルと kubeadmin 認証情報をリソースから直接取得するか、hcp コマンドラインインターフェイスを使用して kubeconfig ファイルを生成します。

  • リソースから kubeconfig ファイルと認証情報を直接取得し、ホステッドクラスターにアクセスするには、Hosted Control Plane クラスターのアクセスシークレットを理解しておく必要があります。シークレットは、ホステッドクラスター (ホスティング) namespace に保存されます。ホステッドクラスター (ホスティング) namespace にはホステッドクラスターリソースが含まれており、Hosted Control Plane namespace では Hosted Control Plane が実行されます。

    シークレット名の形式は次のとおりです。

    • kubeconfig シークレット: <hosted-cluster-namespace>-<name>-admin-kubeconfig (clusters-hypershift-demo-admin-kubeconfig)

    • kubeadmin パスワードシークレット: <hosted-cluster-namespace>-<name>-kubeadmin-password (clusters-hypershift-demo-kubeadmin-password)

      kubeconfig シークレットには Base64 でエンコードされた kubeconfig フィールドが含まれており、これをデコードしてファイルに保存し、次のコマンドで使用できます。 

      oc --kubeconfig <hosted-cluster-name>.kubeconfig get nodes

    kubeadmin パスワードシークレットも Base64 でエンコードされます。これをデコードし、そのパスワードを使用して、ホステッドクラスターの API サーバーまたはコンソールにログインできます。

  • hcp CLI を使用してホステッドクラスターにアクセスして kubeconfig ファイルを生成するには、次の手順を実行します。

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

      hcp create kubeconfig --namespace <hosted-cluster-namespace> --name <hosted-cluster-name> > <hosted-cluster-name>.kubeconfig

    2. kubeconfig ファイルを保存した後、次のコマンド例を入力して、ホステッドクラスターにアクセスできます。 

      oc --kubeconfig <hosted-cluster-name>.kubeconfig get nodes
1.7.6.10.1. 関連情報

ホステッドクラスターへのアクセス後に、ノードプールをスケーリングしたり、ホステッドクラスターのノード自動スケーリングを有効にしたりできます。詳細は、以下のトピックを参照してください。

ホステッドクラスターのノード調整を設定するには、次のトピックを参照してください。

1.7.6.11. プライベートのホステッドクラスターを AWS にデプロイする (テクノロジープレビュー)

Hosted Control Plane (hcp) コマンドラインインターフェイスを設定し、ローカルクラスターを ホスティングクラスターとして有効にすると、ホステッドクラスターまたはプライベートのホステッドクラスターを AWS にデプロイできます。パブリックのホステッドクラスターを AWS にデプロイするには、AWS でのホステッドクラスターのデプロイ を参照してください。

デフォルトでは、Hosted Control Plane のゲストクラスターは、パブリック DNS および管理クラスターのデフォルトルーターを通じてパブリックにアクセスできます。

AWS のプライベートクラスターの場合、ゲストクラスターとのすべての通信は AWS PrivateLink 経由で行われます。AWS でプライベートクラスターをサポートするように Hosted Control Plane を設定するには、次の手順を実行します。

重要: パブリッククラスターは任意のリージョンに作成できますが、プライベートクラスターは --aws-private-region で指定されたリージョンにのみ作成できます。

1.7.6.11.1. 前提条件

AWS のプライベートホストクラスターを有効にするには、まず AWS PrivateLink を有効にする必要があります。詳細は、AWS PrivateLink の有効化 を参照してください。

1.7.6.11.2. AWS 上でプライベートホストクラスターを作成する

  1. 次のコマンドを入力して、プライベートクラスター IAM ポリシードキュメントを作成します。 

    cat << EOF >> policy.json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:CreateVpcEndpointServiceConfiguration",
        "ec2:DescribeVpcEndpointServiceConfigurations",
        "ec2:DeleteVpcEndpointServiceConfigurations",
        "ec2:DescribeVpcEndpointServicePermissions",
        "ec2:ModifyVpcEndpointServicePermissions",
        "ec2:CreateTags",
        "elasticloadbalancing:DescribeLoadBalancers"
      ],
      "Resource": "\*"
    }
  ]
}

  2. 次のコマンドを入力して、AWS で IAM ポリシーを作成します。 

    aws iam create-policy --policy-name=hypershift-operator-policy --policy-document=file://policy.json

  3. 次のコマンドを入力して、hypershift-operator IAM ユーザーを作成します。 

    aws iam create-user --user-name=hypershift-operator

  4. 次のコマンドを入力して、ポリシーを hypershift-operator ユーザーにアタッチします。<policy-arn> は、作成したポリシーの ARN に置き換えます。 

    aws iam attach-user-policy --user-name=hypershift-operator --policy-arn=<policy-arn>

  5. 次のコマンドを入力して、ユーザーの IAM アクセスキーを作成します。 

    aws iam create-access-key --user-name=hypershift-operator

  6. 次のコマンドを入力して、プライベートホストクラスターを作成します。必要に応じて、変数を実際の値に置き換えます。 

    hcp create cluster aws \
--name <hosted-cluster-name> \ 1
--node-pool-replicas=<node-pool-replica-count> \ 2
--base-domain <basedomain> \ 3
--pull-secret <path-to-pull-secret> \ 4
--aws-creds <path-to-aws-credentials> \ 5
--region <region> \ 6
--endpoint-access Private 7
    1 1
    ホステッドクラスターの名前を指定します (例: example)。
    2 2
    ノードプールのレプリカ数を指定します (例: 3)。
    3
    ベースドメインを指定します (例: example.com)。
    4
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    5
    AWS 認証情報ファイルへのパスを指定します (例: /user/name/.aws/credentials)。
    6
    AWS リージョン名を指定します (例: us-east-1)。
    7
    クラスターがパブリックかプライベートかを定義します。

    クラスターの API エンドポイントには、プライベート DNS ゾーンを通じてアクセスできます。

    • api.<hosted-cluster-name>.hypershift.local
    • *.apps.<hosted-cluster-name>.hypershift.local
1.7.6.11.3. AWS 上のプライベートホスティングクラスターへのアクセス

踏み台インスタンスを使用してプライベートクラスターにアクセスできます。

  1. 次のコマンドを入力して、踏み台インスタンスを起動します。 

    hypershift create bastion aws --aws-creds=<aws-creds> --infra-id=<infra-id> --region=<region> --ssh-key-file=<ssh-key>

    <ssh-key> を、踏み台に接続するための SSH 公開鍵ファイルに置き換えます。SSH 公開鍵ファイルのデフォルトの場所は ~/.ssh/id_rsa.pub です。<aws-creds> を AWS 認証情報ファイルへのパスに置き換えます (例: /user/name/.aws/credentials)。

注記: hypershift CLI はダウンロードできません。次のコマンドを使用して、hypershift namespace に存在する HyperShift Operator Pod を使用して CLI を抽出してください。<hypershift-operator-pod-name> は、HyperShift Operator Pod 名に置き換えてください。 

oc project hypershift
oc rsync <hypershift-operator-pod-name>:/usr/bin/hypershift-no-cgo .
mv hypershift-no-cgo hypershift

  1. 次のコマンドを入力して、クラスターノードプール内のノードのプライベート IP を検索します。 

    aws ec2 describe-instances --filter="Name=tag:kubernetes.io/cluster/<infra-id>,Values=owned" | jq '.Reservations[] | .Instances[] | select(.PublicDnsName=="") | .PrivateIpAddress'

  2. 次のコマンドを入力して、ノードにコピーできるクラスターの kubeconfig ファイルを作成します。 

    hcp create kubeconfig > <cluster-kubeconfig>

  3. 次のコマンドを入力して、create bastion コマンドから出力された IP を使用して踏み台を介していずれかのノードに SSH 接続します。 

    ssh -o ProxyCommand="ssh ec2-user@<bastion-ip> -W %h:%p" core@<node-ip>

  4. SSH シェルから、次のコマンドを入力して、kubeconfig ファイルの内容をノード上のファイルにコピーします。 

    mv <path-to-kubeconfig-file> <new-file-name>

  5. 次のコマンドを入力して、kubeconfig ファイルをエクスポートします。 

    export KUBECONFIG=<path-to-kubeconfig-file>

  6. 次のコマンドを入力して、ゲストクラスターのステータスを確認します。 

    oc get clusteroperators clusterversion
1.7.6.11.4. 関連情報

AWS でのパブリックホステッドクラスターのデプロイの詳細は、AWS でのホステッドクラスターのデプロイ を参照してください。

1.7.6.12. AWS インフラストラクチャーと Hosted Control Plane の IAM 権限の管理 (テクノロジープレビュー)

AWS で Red Hat OpenShift Container Platform のホストされているコントロールプレーンを使用する場合、インフラストラクチャーの要件はセットアップに応じて異なります。

1.7.6.12.1. 前提条件

Hosted Control Plane クラスターを作成する前に、Hosted Control Plane を設定する必要があります。詳細は、AWS での Hosted Control Plane クラスターの設定 (テクノロジープレビュー) を参照してください。

1.7.6.12.2. AWS インフラストラクチャーの要件

AWS で Hosted Control Plane を使用する場合、インフラストラクチャー要件は次のカテゴリーに当てはまります。

  • 任意の AWS アカウントの HyperShift Operator に必要なマネージド外のインフラストラクチャー
  • ホステッドクラスターの AWS アカウントで事前に必要なマネージド外のインフラストラクチャー
  • 管理 AWS アカウント内の Hosted Control Plane 管理インフラストラクチャー
  • ホステッドクラスター内の Hosted Control Plane 管理インフラストラクチャー AWS アカウント
  • ホステッドクラスターの Kubernetes 管理インフラストラクチャー AWS アカウント

Prerequired とは、Hosted Control Plane が適切に動作するために AWS インフラストラクチャーが必要であることを意味します。Unmanaged とは、Operator またはコントローラーがインフラストラクチャーを作成しないことを意味します。次のセクションには、AWS リソースの作成に関する詳細が含まれています。

1.7.6.12.2.1. 任意の AWS アカウントの HyperShift Operator に必要なマネージド外のインフラストラクチャー

任意の AWS アカウントは、ホストされるコントロールプレーンサービスのプロバイダーに依存します。

自己管理型の Hosted Control Plane では、クラスターサービスプロバイダーが AWS アカウントを制御します。クラスターサービスプロバイダー は、クラスターコントロールプレーンをホストする管理者であり、アップタイムを行います。管理対象の Hosted Control Plane では、AWS アカウントは Red Hat に属します。

HyperShift Operator の必須の非管理インフラストラクチャーでは、管理クラスター AWS アカウントに次のインフラストラクチャー要件が適用されます。

  • 1 つの S3 バケット

    • OpenID Connect (OIDC)

  • ルート 53 のホステッドゾーン

    • ホステッドクラスターのプライベートおよびパブリックエントリーをホストするドメイン
1.7.6.12.2.2. ホステッドクラスターの AWS アカウントで事前に必要なマネージド外のインフラストラクチャー

インフラストラクチャーが事前に必要であり、ホステッドクラスター AWS アカウントで管理されていない場合、すべてのアクセスモードのインフラストラクチャー要件は次のとおりです。

  • 1 つの VPC
  • 1 つの DHCP オプション

  • 2 つのサブネット

    • 内部データプレーンサブネットであるプライベートサブネット
    • データプレーンからインターネットへのアクセスを可能にするパブリックサブネット
  • 1 つのインターネットゲートウェイ
  • 1 つの Elastic IP
  • 1 つの NAT ゲートウェイ
  • 1 つのセキュリティーグループ (ワーカーノード)
  • 2 つのルートテーブル (1 つはプライベート、もう 1 つはパブリック)
  • 2 つの Route 53 のホステッドゾーン

  • 次のアイテムに対して十分な割り当てがあります:

    • パブリックホストクラスター用の 1 つの Ingress サービスロードバランサー
    • プライベートホストクラスター用の 1 つのプライベートリンクエンドポイント

注記: プライベートリンクネットワーキングが機能するには、ホステッドクラスター AWS アカウントのエンドポイントゾーンが、管理クラスター AWS アカウントのサービスエンドポイントによって解決されるインスタンスのゾーンと一致する必要があります。AWS では、ゾーン名は us-east-2b などのエイリアスであり、異なるアカウントの同じゾーンにマップされるとは限りません。そのため、プライベートリンクが機能するには、管理クラスターのリージョンのすべてのゾーンにサブネットまたはワーカーが必要です。

1.7.6.12.2.3. 管理 AWS アカウント内の Hosted Control Plane 管理インフラストラクチャー

インフラストラクチャーが管理 AWS アカウントの Hosted Control Plane によって管理されている場合、インフラストラクチャーの要件は、クラスターがパブリック、プライベート、またはその組み合わせであるかによって異なります。

パブリッククラスターを使用するアカウントの場合、インフラストラクチャー要件は次のとおりです。

  • ネットワークロードバランサー: ロードバランサー Kube API サーバー

    • Kubernetes がセキュリティーグループを作成する

  • Volumes

    • etcd の場合 (高可用性に応じて 1 つまたは 3 つ)
    • OVN-Kube の場合

プライベートクラスターを使用するアカウントの場合、インフラストラクチャー要件は次のとおりです。

  • ネットワークロードバランサー: ロードバランサーのプライベートルーター
  • エンドポイントサービス (プライベートリンク)

パブリッククラスターとプライベートクラスターを持つアカウントの場合、インフラストラクチャー要件は次のとおりです。

  • ネットワークロードバランサー: ロードバランサーのパブリックルーター
  • ネットワークロードバランサー: ロードバランサーのプライベートルーター
  • エンドポイントサービス (プライベートリンク)

  • Volumes:

    • etcd の場合 (高可用性に応じて 1 つまたは 3 つ)
    • OVN-Kube の場合
1.7.6.12.2.4. ホステッドクラスター内の Hosted Control Plane 管理インフラストラクチャー AWS アカウント

インフラストラクチャーがホステッドクラスター AWS アカウントの Hosted Control Plane によって管理されている場合、インフラストラクチャー要件は、クラスターがパブリック、プライベート、またはその組み合わせであるかによって異なります。

パブリッククラスターを使用するアカウントの場合、インフラストラクチャー要件は次のとおりです。

  • ノードプールには、Role と RolePolicy が定義された EC2 インスタンスが必要です。

プライベートクラスターを使用するアカウントの場合、インフラストラクチャー要件は次のとおりです。

  • アベイラビリティーゾーンごとに 1 つのプライベートリンクエンドポイント
  • ノードプールの EC2 インスタンス

パブリッククラスターとプライベートクラスターを持つアカウントの場合、インフラストラクチャー要件は次のとおりです。

  • アベイラビリティーゾーンごとに 1 つのプライベートリンクエンドポイント
  • ノードプールの EC2 インスタンス
1.7.6.12.2.5. ホステッドクラスターの Kubernetes 管理インフラストラクチャー AWS アカウント

Kubernetes がホステッドクラスター AWS アカウントでインフラストラクチャーを管理する場合、インフラストラクチャー要件は次のとおりです。

  • デフォルトの Ingress 用のネットワークロードバランサー
  • レジストリー用の S3 バケット
1.7.6.12.3. Identity and Access Management (IAM) 権限

Hosted Control Plane のコンテキストでは、コンシューマーは Amazon リソースネーム (ARN) ロールを作成する責任があります。コンシューマー は、アクセス許可ファイルを生成する自動プロセスです。コンシューマーはコマンドラインインターフェイスまたは OpenShift Cluster Manager である可能性があります。Hosted Control Plane は、最小特権コンポーネントの原則を尊重する粒度を有効にしようとします。つまり、すべてのコンポーネントが独自のロールを使用して AWS オブジェクトを操作または作成し、ロールは製品が正常に機能するために必要なものに限定されます。

コマンドラインインターフェイスで ARN ロールを作成する方法の例は、「AWS インフラストラクチャーと IAM リソースを個別に作成する」を参照してください。

ホステッドクラスターは ARN ロールを入力として受け取り、コンシューマーは各コンポーネントの AWS 権限設定を作成します。その結果、コンポーネントは STS および事前設定された OIDC IDP を通じて認証できるようになります。

次のロールは、コントロールプレーン上で実行され、データプレーン上で動作する、Hosted Control Plane の一部のコンポーネントによって消費されます。

  • controlPlaneOperatorARN
  • imageRegistryARN
  • ingressARN
  • kubeCloudControllerARN
  • nodePoolManagementARN
  • storageARN
  • networkARN

次の例は、ホステッドクラスターからの IAM ロールへの参照を示しています。 

...
endpointAccess: Public
  region: us-east-2
  resourceTags:
  - key: kubernetes.io/cluster/example-cluster-bz4j5
    value: owned
rolesRef:
    controlPlaneOperatorARN: arn:aws:iam::820196288204:role/example-cluster-bz4j5-control-plane-operator
    imageRegistryARN: arn:aws:iam::820196288204:role/example-cluster-bz4j5-openshift-image-registry
    ingressARN: arn:aws:iam::820196288204:role/example-cluster-bz4j5-openshift-ingress
    kubeCloudControllerARN: arn:aws:iam::820196288204:role/example-cluster-bz4j5-cloud-controller
    networkARN: arn:aws:iam::820196288204:role/example-cluster-bz4j5-cloud-network-config-controller
    nodePoolManagementARN: arn:aws:iam::820196288204:role/example-cluster-bz4j5-node-pool
    storageARN: arn:aws:iam::820196288204:role/example-cluster-bz4j5-aws-ebs-csi-driver-controller
type: AWS
...

Hosted Control Plane が使用するロールを次の例に示します。

  • ingressARN 

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "elasticloadbalancing:DescribeLoadBalancers",
                "tag:GetResources",
                "route53:ListHostedZones"
            ],
            "Resource": "\*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "route53:ChangeResourceRecordSets"
            ],
            "Resource": [
                "arn:aws:route53:::PUBLIC_ZONE_ID",
                "arn:aws:route53:::PRIVATE_ZONE_ID"
            ]
        }
    ]
}

  • imageRegistryARN 

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:CreateBucket",
                "s3:DeleteBucket",
                "s3:PutBucketTagging",
                "s3:GetBucketTagging",
                "s3:PutBucketPublicAccessBlock",
                "s3:GetBucketPublicAccessBlock",
                "s3:PutEncryptionConfiguration",
                "s3:GetEncryptionConfiguration",
                "s3:PutLifecycleConfiguration",
                "s3:GetLifecycleConfiguration",
                "s3:GetBucketLocation",
                "s3:ListBucket",
                "s3:GetObject",
                "s3:PutObject",
                "s3:DeleteObject",
                "s3:ListBucketMultipartUploads",
                "s3:AbortMultipartUpload",
                "s3:ListMultipartUploadParts"
            ],
            "Resource": "\*"
        }
    ]
}

  • storageARN 

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:AttachVolume",
                "ec2:CreateSnapshot",
                "ec2:CreateTags",
                "ec2:CreateVolume",
                "ec2:DeleteSnapshot",
                "ec2:DeleteTags",
                "ec2:DeleteVolume",
                "ec2:DescribeInstances",
                "ec2:DescribeSnapshots",
                "ec2:DescribeTags",
                "ec2:DescribeVolumes",
                "ec2:DescribeVolumesModifications",
                "ec2:DetachVolume",
                "ec2:ModifyVolume"
            ],
            "Resource": "\*"
        }
    ]
}

  • networkARN 

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeInstances",
                "ec2:DescribeInstanceStatus",
                "ec2:DescribeInstanceTypes",
                "ec2:UnassignPrivateIpAddresses",
                "ec2:AssignPrivateIpAddresses",
                "ec2:UnassignIpv6Addresses",
                "ec2:AssignIpv6Addresses",
                "ec2:DescribeSubnets",
                "ec2:DescribeNetworkInterfaces"
            ],
            "Resource": "\*"
        }
    ]
}

  • kubeCloudControllerARN 

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "ec2:DescribeInstances",
                "ec2:DescribeImages",
                "ec2:DescribeRegions",
                "ec2:DescribeRouteTables",
                "ec2:DescribeSecurityGroups",
                "ec2:DescribeSubnets",
                "ec2:DescribeVolumes",
                "ec2:CreateSecurityGroup",
                "ec2:CreateTags",
                "ec2:CreateVolume",
                "ec2:ModifyInstanceAttribute",
                "ec2:ModifyVolume",
                "ec2:AttachVolume",
                "ec2:AuthorizeSecurityGroupIngress",
                "ec2:CreateRoute",
                "ec2:DeleteRoute",
                "ec2:DeleteSecurityGroup",
                "ec2:DeleteVolume",
                "ec2:DetachVolume",
                "ec2:RevokeSecurityGroupIngress",
                "ec2:DescribeVpcs",
                "elasticloadbalancing:AddTags",
                "elasticloadbalancing:AttachLoadBalancerToSubnets",
                "elasticloadbalancing:ApplySecurityGroupsToLoadBalancer",
                "elasticloadbalancing:CreateLoadBalancer",
                "elasticloadbalancing:CreateLoadBalancerPolicy",
                "elasticloadbalancing:CreateLoadBalancerListeners",
                "elasticloadbalancing:ConfigureHealthCheck",
                "elasticloadbalancing:DeleteLoadBalancer",
                "elasticloadbalancing:DeleteLoadBalancerListeners",
                "elasticloadbalancing:DescribeLoadBalancers",
                "elasticloadbalancing:DescribeLoadBalancerAttributes",
                "elasticloadbalancing:DetachLoadBalancerFromSubnets",
                "elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
                "elasticloadbalancing:ModifyLoadBalancerAttributes",
                "elasticloadbalancing:RegisterInstancesWithLoadBalancer",
                "elasticloadbalancing:SetLoadBalancerPoliciesForBackendServer",
                "elasticloadbalancing:AddTags",
                "elasticloadbalancing:CreateListener",
                "elasticloadbalancing:CreateTargetGroup",
                "elasticloadbalancing:DeleteListener",
                "elasticloadbalancing:DeleteTargetGroup",
                "elasticloadbalancing:DescribeListeners",
                "elasticloadbalancing:DescribeLoadBalancerPolicies",
                "elasticloadbalancing:DescribeTargetGroups",
                "elasticloadbalancing:DescribeTargetHealth",
                "elasticloadbalancing:ModifyListener",
                "elasticloadbalancing:ModifyTargetGroup",
                "elasticloadbalancing:RegisterTargets",
                "elasticloadbalancing:SetLoadBalancerPoliciesOfListener",
                "iam:CreateServiceLinkedRole",
                "kms:DescribeKey"
            ],
            "Resource": [
                "\*"
            ],
            "Effect": "Allow"
        }
    ]
}

  • nodePoolManagementARN 

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "ec2:AllocateAddress",
                "ec2:AssociateRouteTable",
                "ec2:AttachInternetGateway",
                "ec2:AuthorizeSecurityGroupIngress",
                "ec2:CreateInternetGateway",
                "ec2:CreateNatGateway",
                "ec2:CreateRoute",
                "ec2:CreateRouteTable",
                "ec2:CreateSecurityGroup",
                "ec2:CreateSubnet",
                "ec2:CreateTags",
                "ec2:DeleteInternetGateway",
                "ec2:DeleteNatGateway",
                "ec2:DeleteRouteTable",
                "ec2:DeleteSecurityGroup",
                "ec2:DeleteSubnet",
                "ec2:DeleteTags",
                "ec2:DescribeAccountAttributes",
                "ec2:DescribeAddresses",
                "ec2:DescribeAvailabilityZones",
                "ec2:DescribeImages",
                "ec2:DescribeInstances",
                "ec2:DescribeInternetGateways",
                "ec2:DescribeNatGateways",
                "ec2:DescribeNetworkInterfaces",
                "ec2:DescribeNetworkInterfaceAttribute",
                "ec2:DescribeRouteTables",
                "ec2:DescribeSecurityGroups",
                "ec2:DescribeSubnets",
                "ec2:DescribeVpcs",
                "ec2:DescribeVpcAttribute",
                "ec2:DescribeVolumes",
                "ec2:DetachInternetGateway",
                "ec2:DisassociateRouteTable",
                "ec2:DisassociateAddress",
                "ec2:ModifyInstanceAttribute",
                "ec2:ModifyNetworkInterfaceAttribute",
                "ec2:ModifySubnetAttribute",
                "ec2:ReleaseAddress",
                "ec2:RevokeSecurityGroupIngress",
                "ec2:RunInstances",
                "ec2:TerminateInstances",
                "tag:GetResources",
                "ec2:CreateLaunchTemplate",
                "ec2:CreateLaunchTemplateVersion",
                "ec2:DescribeLaunchTemplates",
                "ec2:DescribeLaunchTemplateVersions",
                "ec2:DeleteLaunchTemplate",
                "ec2:DeleteLaunchTemplateVersions"
            ],
            "Resource": [
                "\*"
            ],
            "Effect": "Allow"
        },
        {
            "Condition": {
                "StringLike": {
                    "iam:AWSServiceName": "elasticloadbalancing.amazonaws.com"
                }
            },
            "Action": [
                "iam:CreateServiceLinkedRole"
            ],
            "Resource": [
                "arn:*:iam::*:role/aws-service-role/elasticloadbalancing.amazonaws.com/AWSServiceRoleForElasticLoadBalancing"
            ],
            "Effect": "Allow"
        },
        {
            "Action": [
                "iam:PassRole"
            ],
            "Resource": [
                "arn:*:iam::*:role/*-worker-role"
            ],
            "Effect": "Allow"
        }
    ]
}

  • controlPlaneOperatorARN 

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:CreateVpcEndpoint",
                "ec2:DescribeVpcEndpoints",
                "ec2:ModifyVpcEndpoint",
                "ec2:DeleteVpcEndpoints",
                "ec2:CreateTags",
                "route53:ListHostedZones"
            ],
            "Resource": "\*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "route53:ChangeResourceRecordSets",
                "route53:ListResourceRecordSets"
            ],
            "Resource": "arn:aws:route53:::%s"
        }
    ]
}
1.7.6.12.4. AWS インフラストラクチャーと IAM リソースを個別に作成する

デフォルトでは、hcp create cluster aws コマンドは、ホステッドクラスターを使用してクラウドインフラストラクチャーを作成し、それを適用します。クラウドインフラストラクチャー部分を個別に作成して、hcp create cluster aws コマンドをクラスターの作成のみに使用したり、クラスターを適用する前に変更できるようにレンダリングしたりすることができます。

クラウドインフラストラクチャー部分を個別に作成するには、AWS インフラストラクチャーを作成し、AWS Identity and Access (IAM) リソースを作成し、クラスターを作成する必要があります。

1.7.6.12.4.1. AWS インフラストラクチャーの作成

AWS インフラストラクチャーを作成するには、次のコマンドを入力します。 

hypershift create infra aws --name CLUSTER_NAME \ 1
    --aws-creds AWS_CREDENTIALS_FILE \ 2
    --base-domain BASEDOMAIN \ 3
    --infra-id INFRA_ID \ 4
    --region REGION \ 5
    --output-file OUTPUT_INFRA_FILE 6
1
CLUSTER_NAME を、作成しているホステッドクラスターの名前に置き換えます。この値は、クラスターの Route 53 プライベートのホステッドゾーンを作成するために使用されます。
2
AWS_CREDENTIALS_FILE を、VPC、サブネット、NAT ゲートウェイなどのクラスターのインフラストラクチャーリソースを作成する権限を持つ AWS 認証情報ファイルの名前に置き換えます。この値は、ワーカーが存在するゲストクラスターの AWS アカウントに対応する必要があります。
3
BASEDOMAIN を、ホステッドクラスター Ingress に使用する予定のベースドメインの名前に置き換えます。この値は、レコードを作成できる Route 53 パブリックゾーンに対応している必要があります。
4
INFRA_ID をタグを使用してインフラストラクチャーを識別する一意の名前に置き換えます。この値は、Kubernetes のクラウドコントローラーマネージャーとクラスター API マネージャーによってクラスターのインフラストラクチャーを識別するために使用されます。通常、この値はクラスターの名前 (CLUSTER_NAME) に接尾辞を追加したものです。
5
REGION をクラスターのインフラストラクチャーを作成するリージョンに置き換えます。
6
OUTPUT_INFRA_FILE をインフラストラクチャーの ID を JSON 形式で保存するファイルの名前に置き換えます。このファイルを hcp create cluster aws コマンドへの入力として使用し、HostedCluster リソースと NodePool リソースのフィールドに値を設定できます。

注記: hypershift CLI はダウンロードできません。次のコマンドを使用して、hypershift namespace に存在する HyperShift Operator Pod を使用して CLI を抽出してください。<hypershift-operator-pod-name> は、HyperShift Operator Pod 名に置き換えてください。

+ 

oc project hypershift
oc rsync <hypershift-operator-pod-name>:/usr/bin/hypershift-no-cgo .
mv hypershift-no-cgo hypershift

コマンドを入力すると、次のリソースが作成されます。

  • 1 つの VPC
  • 1 つの DHCP オプション
  • 1 つのプライベートサブネット
  • 1 つのパブリックサブネット
  • 1 つのインターネットゲートウェイ
  • 1 つの NAT ゲートウェイ
  • ワーカーノード用の 1 つのセキュリティーグループ
  • 2 つのルートテーブル: 1 つはプライベート、もう 1 つはパブリック
  • 2 つのプライベートホストゾーン: クラスター Ingress 用に 1 つ、PrivateLink 用に 1 つ (プライベートクラスターを作成する場合)

これらのリソースにはすべて、kubernetes.io/cluster/INFRA_ID=owned タグが含まれています。ここで、INFRA_ID はコマンドで指定した値です。

1.7.6.12.4.2. AWS IAM リソースの作成

AWS IAM リソースを作成するには、次のコマンドを入力します。 

hypershift create iam aws --infra-id INFRA_ID \ 1
    --aws-creds AWS_CREDENTIALS_FILE \ 2
    --oidc-storage-provider-s3-bucket-name OIDC_BUCKET_NAME \ 3
    --oidc-storage-provider-s3-region OIDC_BUCKET_REGION \ 4
    --region REGION \ 5
    --public-zone-id PUBLIC_ZONE_ID \ 6
    --private-zone-id PRIVATE_ZONE_ID \ 7
    --local-zone-id LOCAL_ZONE_ID \ 8
    --output-file OUTPUT_IAM_FILE 9
1
INFRA_ID を create infra aws コマンドで指定したのと同じ ID に置き換えます。この値は、ホステッドクラスターに関連付けられている IAM リソースを識別します。
2
AWS_CREDENTIALS_FILE をロールなどの IAM リソースを作成する権限を持つ AWS 認証情報ファイルの名前に置き換えます。このファイルは、インフラストラクチャーを作成するために指定した認証情報ファイルと同じである必要はありませんが、同じ AWS アカウントに対応している必要があります。
3
OIDC_BUCKET_NAME を、OIDC ドキュメントを保存するバケットの名前に置き換えます。このバケットは、Hosted Control Plane をインストールするための前提条件として作成されました。バケットの名前は、このコマンドによって作成される OIDC プロバイダーの URL を構築するために使用されます。
4
OIDC_BUCKET_REGION を、OIDC バケットが存在するリージョンに置き換えます。
5
REGION をクラスターのインフラストラクチャーが配置されているリージョンに置き換えます。この値は、ホステッドクラスターに属するマシンのワーカーインスタンスプロファイルを作成するために使用されます。
6
PUBLIC_ZONE_ID をゲストクラスターのパブリックゾーンの ID に置き換えます。この値は、Ingress Operator のポリシーを作成するために使用されます。この値は create infra aws コマンドによって生成される OUTPUT_INFRA_FILE で確認できます。
7
PRIVATE_ZONE_ID をゲストクラスターのプライベートゾーンの ID に置き換えます。この値は、Ingress Operator のポリシーを作成するために使用されます。この値は create infra aws コマンドによって生成される OUTPUT_INFRA_FILE で確認できます。
8
LOCAL_ZONE_ID は、プライベートクラスターの作成時にゲストクラスターのローカルゾーンの ID に置き換えます。この値は、コントロールプレーンオペレーターのポリシーを作成するために使用され、PrivateLink エンドポイントのレコードを管理できるようになります。この値は create infra aws コマンドによって生成される OUTPUT_INFRA_FILE で確認できます。
9
OUTPUT_IAM_FILE を IAM リソースの ID を JSON 形式で保存するファイルの名前に置き換えます。その後、このファイルを hcp create cluster aws コマンドへの入力として使用して、HostedCluster リソースと NodePool リソースのフィールドに値を設定できます。

コマンドを入力すると、次のリソースが作成されます。

  • 1 つの OIDC プロバイダー。STS 認証を有効にするために必要です。
  • 7 つのロール。Kubernetes コントローラーマネージャー、クラスター API プロバイダー、レジストリーなど、プロバイダーと対話するコンポーネントごとに分かれています。
  • 1 つのインスタンスプロファイル。クラスターのすべてのワーカーインスタンスに割り当てられるプロファイルです。
1.7.6.12.4.3. クラスターの作成

クラスターを作成するには、次のコマンドを入力します。 

hcp create cluster aws \
    --infra-id INFRA_ID \ 1
    --name CLUSTER_NAME \ 2
    --aws-creds AWS_CREDENTIALS \ 3
    --pull-secret PULL_SECRET_FILE \ 4
    --generate-ssh \ 5
    --node-pool-replicas 3
1
INFRA_ID を create infra aws コマンドで指定したのと同じ ID に置き換えます。この値は、ホステッドクラスターに関連付けられている IAM リソースを識別します。
2
CLUSTER_NAME を create infra aws コマンドで指定したのと同じ名前に置き換えます。
3
AWS_CREDENTIALS を create infra aws コマンドで指定したのと同じ値に置き換えます。
4
PULL_SECRET_FILE を有効な OpenShift Container Platform プルシークレットを含むファイルの名前に置き換えます。
5
--generate-ssh フラグはオプションですが、ワーカーに SSH 接続する必要がある場合に含めるとよいでしょう。SSH キーが生成され、ホステッドクラスターと同じ名 namespace にシークレットとして保存されます。

コマンドに --render フラグを追加して、クラスターに適用する前にリソースを編集できるファイルに出力をリダイレクトすることもできます。

コマンドを実行すると、次のリソースがクラスターに適用されます。

  • namespace
  • プルシークレットの秘密
  • HostedCluster
  • NodePool
  • コントロールプレーンコンポーネントの 3 つの AWS STS シークレット
  • --generate-ssh フラグを指定した場合は、1 つの SSH キーシークレット。

1.7.6.13. AWS でのホステッドクラスターの破棄

ホステッドクラスターとそのマネージドクラスターリソースを破棄するには、次の手順を実行します。

  1. 次のコマンドを実行して、マルチクラスターエンジン Operator のマネージドクラスターリソースを削除します。 

    oc delete managedcluster <managed_cluster_name>

    ここで、<managed_cluster_name> は管理対象クラスターの名前です。

  2. 次のコマンドを実行して、ホステッドクラスターとそのバックエンドリソースを削除します。 

    hcp destroy cluster aws --name <hosted_cluster_name> --infra-id <infra_id> --aws-creds <path_to_aws_creds> --base-domain <basedomain>

    必要に応じて名前を置き換えます。

1.7.7. ベアメタルでの Hosted Control Plane クラスターの設定

ホスティングクラスターとして機能するようにクラスターを設定することで、Hosted Control Plane をデプロイメントできます。ホスティングクラスターは、コントロールプレーンがホストされる OpenShift Container Platform クラスターです。ホスティングクラスターは 管理 クラスターとも呼ばれます。

注記: 管理クラスターは、マネージド クラスターとは異なります。マネージドクラスターは、ハブクラスターが管理するクラスターです。

Hosted Control Plane 機能がデフォルトで有効になりました。

マルチクラスターエンジン Operator 2.5 は、管理対象のハブクラスターであるデフォルトの local-cluster と、ホスティングクラスターとしてのハブクラスターのみをサポートします。Red Hat Advanced Cluster Management 2.10 では、マネージドハブクラスター (local-cluster) をホスティングクラスターとして使用できます。

ホストされたクラスター は、ホスティングクラスターでホストされる API エンドポイントとコントロールプレーンを含む OpenShift Container Platform クラスターです。ホステッドクラスターには、コントロールプレーンとそれに対応するデータプレーンが含まれます。マルチクラスターエンジンの Operator コンソールまたは Hosted Control Plane のコマンドラインインターフェイス hcp を使用して、ホステッドクラスターを作成できます。ホステッドクラスターは、マネージドクラスターとして自動的にインポートされます。この自動インポート機能を無効にする場合は、マルチクラスターエンジン Operator へのホストクラスターの自動インポートの無効化 を参照してください。

重要:

  • Hosted Control Plane の同じプラットフォームで、ハブクラスターとワーカーを実行します。
  • 各ホステッドクラスターに、クラスター全体で一意の名前が必要です。マルチクラスターエンジン Operator によってホストクラスターを管理するには、ホストクラスター名を既存のマネージドクラスターと同じにすることはできません。
  • ホステッドクラスター名として clusters を使用しないでください。
  • ホステッドクラスターは、マルチクラスターエンジンの operator 管理クラスターの namespace には作成できません。
  • エージェントプラットフォームを使用して、Hosted Control Plane をベアメタルでプロビジョニングできます。Agent プラットフォームは、Central Infrastructure Management サービスを使用して、ホステッドクラスターにワーカーノードを追加します。Central Infrastructure Management の概要は、central infrastructure management の有効化 を参照してください。
  • すべてのベアメタルホストでは、Central Infrastructure Management が提供する検出イメージ ISO を使用して手動でブートする必要があります。ホストは手動で起動することも、Cluster-Baremetal-Operator を使用して自動化することもできます。各ホストが起動すると、エージェントプロセスが実行され、ホストの詳細が検出され、インストールが完了します。Agent カスタムリソースは、各ホストを表します。
  • Agent プラットフォームでホステッドクラスターを作成すると、HyperShift は Hosted Control Plane namespace に Agent Cluster API プロバイダーをインストールします。
  • ノードプールによってレプリカをスケーリングすると、マシンが作成されます。クラスター API プロバイダーは、すべてのマシンに対して、ノードプール仕様で指定された要件を満たすエージェントを見つけてインストールします。エージェントのステータスと状態を確認することで、エージェントのインストールを監視できます。
  • ノードプールをスケールダウンすると、エージェントは対応するクラスターからバインド解除されます。Agent を再利用するには、Discovery イメージを使用してエージェントを再起動する必要があります。
  • Hosted Control Plane のストレージを設定する場合は、etcd の推奨プラクティスを考慮してください。レイテンシー要件を満たすには、各コントロールプレーンノードで実行されるすべての Hosted Control Plane の etcd インスタンス専用の高速ストレージデバイスを使用します。LVM ストレージを使用して、ホストされた etcd Pod のローカルストレージクラスを設定できます。詳細は、OpenShift Container Platform ドキュメントの 推奨される etcd プラクティス および 論理ボリュームマネージャーストレージを使用した永続ストレージ を参照してください。

1.7.7.1. 前提条件

ホスティングクラスターを設定するには、次の前提条件を満たす必要があります。

  • OpenShift Container Platform クラスターにインストールされた Kubernetes Operator 2.2 以降のマルチクラスターエンジンが必要です。マルチクラスターエンジン Operator は、Red Hat Advanced Cluster Management をインストールすると自動的にインストールされます。OpenShift Container Platform OperatorHub から Operator として Red Hat Advanced Cluster Management を使用せずに、マルチクラスターエンジン Operator をインストールすることもできます。

  • マルチクラスターエンジン Operator には、少なくとも 1 つのマネージド OpenShift Container Platform クラスターが必要です。local-cluster は、マルチクラスターエンジン Operator 2.2 以降で自動的にインポートされます。local-cluster の詳細については、詳細設定 を参照してください。次のコマンドを実行して、ハブクラスターの状態を確認できます。 

    oc get managedclusters local-cluster
  • 管理クラスター上のベアメタルホストに topology.kubernetes.io/zone ラベルを追加する必要があります。そうしないと、すべての Hosted Control Plane Pod が単一ノードでスケジュールされ、単一障害点が発生します。
  • Central Infrastructure Management を有効にする必要があります。詳細は、Central Infrastructure Management サービスの有効化 を参照してください。
  • Hosted Control Plane コマンドラインインターフェイスをインストールする 必要があります。

1.7.7.2. ベアメタルファイアウォール、ポート、およびサービスの要件

管理クラスター、コントロールプレーン、ホストされたクラスター間でポートの通信ができるように、ファイアウォール、ポート、およびサービスの要件を満たす必要があります。

注記: サービスはデフォルトのポートで実行されます。ただし、NodePort 公開ストラテジーを使用する場合、サービスは NodePort サービスによって割り当てられたポートで実行されます。

ファイアウォールルール、セキュリティーグループ、またはその他のアクセス制御を使用して、必要なソースだけにアクセスを制限します。必要な場合を除き、ポートを公開しないでください。実稼働環境の場合は、ロードバランサーを使用して、単一の IP アドレスによるアクセスを簡素化します。

Hosted Control Plane はベアメタル上で次のサービスを公開します。

  • APIServer

    • APIServer サービスはデフォルトでポート 6443 で実行され、コントロールプレーンコンポーネント間の通信には ingress アクセスが必要です。
    • MetalLB ロードバランシングを使用する場合は、ロードバランサーの IP アドレスに使用される IP 範囲への ingress アクセスを許可します。

  • OAuthServer

    • ルートと Ingress を使用してサービスを公開する場合、OAuthServer サービスはデフォルトでポート 443 で実行されます。
    • NodePort 公開ストラテジーを使用する場合は、OAuthServer サービスにファイアウォールルールを使用します。

  • Konnectivity

    • ルートと Ingress を使用してサービスを公開する場合、Konnectivity サービスはデフォルトでポート 443 で実行されます。
    • Konnectivity エージェントは、ホステッドクラスター上で双方向通信を可能にするリバーストンネルを確立し、ポート 6443 でクラスター API サーバーアドレスへの egress アクセスを必要とします。この egress アクセスを使用すると、エージェントは APIServer サービスにアクセスできます。
    • クラスター API サーバーのアドレスが内部 IP アドレスの場合は、ワークロードサブネットからポート 6443 の IP アドレスへのアクセスを許可します。
    • アドレスが外部 IP アドレスの場合は、ノードからその外部 IP アドレスにポート 6443 で送信できるように許可します。

  • Ignition

    • ルートと Ingress を使用してサービスを公開する場合、Ignition サービスはデフォルトでポート 443 で実行されます。
    • NodePort 公開ストラテジーを使用する場合は、Ignition サービスにファイアウォールルールを使用します。

ベアメタルで以下のサービスは必要ありません。

  • OVNSbDb
  • OIDC

1.7.7.3. ベアメタルインフラストラクチャーの要件

エージェントプラットフォームはインフラストラクチャーを作成しませんが、インフラストラクチャーに関して次の要件があります。

  • Agents: Agent は Discovery イメージで起動され、OpenShift Container Platform ノードとしてプロビジョニングする準備ができているホストを表します。
  • DNS: API および Ingress エンドポイントは、ルーティング可能である必要があります。

ベアメタル上の Hosted Control Plane の関連資料については、次のドキュメントを参照してください。

1.7.7.4. ベアメタルでの DNS の設定

ホステッドクラスターの API サーバーは、NodePort サービスとして公開されます。API サーバーに到達できる宛先を指す api.${HOSTED_CLUSTER_NAME}.${BASEDOMAIN} に、DNS エントリーが存在する必要があります。

DNS エントリーは、Hosted Control Plane を実行しているマネージドクラスター内のノードの 1 つを指すレコードと同様、単純化できます。エントリーは、受信トラフィックを Ingress Pod にリダイレクトするためにデプロイされるロードバランサーを指すこともできます。

  • 次の DNS 設定の例を参照してください。 

    api.example.krnl.es.    IN A 192.168.122.20
api.example.krnl.es.    IN A 192.168.122.21
api.example.krnl.es.    IN A 192.168.122.22
api-int.example.krnl.es.    IN A 192.168.122.20
api-int.example.krnl.es.    IN A 192.168.122.21
api-int.example.krnl.es.    IN A 192.168.122.22
`*`.apps.example.krnl.es. IN A 192.168.122.23

  • IPv6 ネットワークで非接続環境の DNS を設定する場合は、次の DNS 設定の例を参照してください。 

    api.example.krnl.es.    IN A 2620:52:0:1306::5
api.example.krnl.es.    IN A 2620:52:0:1306::6
api.example.krnl.es.    IN A 2620:52:0:1306::7
api-int.example.krnl.es.    IN A 2620:52:0:1306::5
api-int.example.krnl.es.    IN A 2620:52:0:1306::6
api-int.example.krnl.es.    IN A 2620:52:0:1306::7
`*`.apps.example.krnl.es. IN A 2620:52:0:1306::10

  • デュアルスタックネットワークの非接続環境で DNS を設定する場合は、IPv4 と IPv6 の両方の DNS エントリーを含めるようにしてください。次の DNS 設定の例を参照してください。 

    host-record=api-int.hub-dual.dns.base.domain.name,192.168.126.10
host-record=api.hub-dual.dns.base.domain.name,192.168.126.10
address=/apps.hub-dual.dns.base.domain.name/192.168.126.11
dhcp-host=aa:aa:aa:aa:10:01,ocp-master-0,192.168.126.20
dhcp-host=aa:aa:aa:aa:10:02,ocp-master-1,192.168.126.21
dhcp-host=aa:aa:aa:aa:10:03,ocp-master-2,192.168.126.22
dhcp-host=aa:aa:aa:aa:10:06,ocp-installer,192.168.126.25
dhcp-host=aa:aa:aa:aa:10:07,ocp-bootstrap,192.168.126.26

host-record=api-int.hub-dual.dns.base.domain.name,2620:52:0:1306::2
host-record=api.hub-dual.dns.base.domain.name,2620:52:0:1306::2
address=/apps.hub-dual.dns.base.domain.name/2620:52:0:1306::3
dhcp-host=aa:aa:aa:aa:10:01,ocp-master-0,[2620:52:0:1306::5]
dhcp-host=aa:aa:aa:aa:10:02,ocp-master-1,[2620:52:0:1306::6]
dhcp-host=aa:aa:aa:aa:10:03,ocp-master-2,[2620:52:0:1306::7]
dhcp-host=aa:aa:aa:aa:10:06,ocp-installer,[2620:52:0:1306::8]
dhcp-host=aa:aa:aa:aa:10:07,ocp-bootstrap,[2620:52:0:1306::9]

次に、ベアメタルに Hosted Control Plane の ホストインベントリーを作成 します。

1.7.7.5. ベアメタルでのホステッドクラスターの作成

ベアメタルでホステッドクラスターを作成するか、インポートできます。ホステッドクラスターをインポートする手順は、ホステッドクラスターのインポート を参照してください。

  1. 次のコマンドを入力して、Hosted Control Plane namespace を作成します。 

    oc create ns <hosted_cluster_namespace>-<hosted_cluster_name>

    <hosted_cluster_namespace> を、ホストされたクラスターの namespace 名 (例: clusters) に置き換えます。<hosted_cluster_name> をホストされたクラスター名に置き換えます。

  2. クラスターにデフォルトのストレージクラスが設定されていることを確認します。そうしないと、保留中の PVC が表示される場合があります。以下のコマンドを実行します。 

    hcp create cluster agent \
    --name=<hosted_cluster_name> \ 1
    --pull-secret=<path_to_pull_secret> \ 2
    --agent-namespace=<hosted_control_plane_namespace> \ 3
    --base-domain=<basedomain> \ 4
    --api-server-address=api.<hosted_cluster_name>.<basedomain> \
    --etcd-storage-class=<etcd_storage_class> \ 5
    --ssh-key  <path_to_ssh_public_key> \ 6
    --namespace <hosted_cluster_namespace> \ 7
    --control-plane-availability-policy SingleReplica \
    --release-image=quay.io/openshift-release-dev/ocp-release:<ocp_release_image> 8
    1
    ホステッドクラスターの名前を指定します (例: example)。
    2
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    3
    Hosted Control Plane namespace を指定します (例: clusters-example)。oc get agent -n <hosted_control_plane_namespace> コマンドを使用して、この namespace でエージェントが使用可能であることを確認します。
    4
    ベースドメインを指定します (例: krnl.es)。
    5
    etcd ストレージクラス名を指定します (例: lvm-storageclass)。
    6
    SSH 公開鍵へのパスを指定します。デフォルトのファイルパスは ~/.ssh/id_rsa.pub です。
    7
    ホストされたクラスターの namespace を指定します。
    8
    使用するサポートされている OpenShift Container Platform のバージョンを指定します (例: 4.14.0-x86_64)。非接続環境を使用している場合は、<ocp_release_image> をダイジェストイメージに置き換えます。OpenShift Container Platform リリースイメージダイジェストを抽出するには、OpenShift Container Platform リリースイメージダイジェストの抽出 を参照してください。

  3. しばらくしてから、次のコマンドを入力して、Hosted Control Plane の Pod が稼働中であることを確認します。 

    oc -n <hosted_control_plane_namespace> get pods

    以下の出力例を参照してください。 

    NAME                                             READY   STATUS    RESTARTS   AGE
capi-provider-7dcf5fc4c4-nr9sq                   1/1     Running   0          4m32s
catalog-operator-6cd867cc7-phb2q                 2/2     Running   0          2m50s
certified-operators-catalog-884c756c4-zdt64      1/1     Running   0          2m51s
cluster-api-f75d86f8c-56wfz                      1/1     Running   0          4m32s
1.7.7.5.1. コンソールを使用してベアメタル上にホストされたクラスターを作成する
  1. OpenShift Container Platform Web コンソールを開き、管理者の認証情報を入力してログインします。コンソールを開く手順については、OpenShift Container Platform ドキュメントの Web コンソールへのアクセス を参照してください。
  2. コンソールヘッダーで、All Clusters が選択されていることを確認します。
  3. Infrastructure > Clusters をクリックします。

  4. Create cluster > Host inventory > Hosted control plane をクリックします。

    Create cluster ページが表示されます。

  5. Create cluster ページでプロンプトに従い、クラスター、ノードプール、ネットワーク、および自動化に関する詳細を入力します。

    注: クラスターに関する詳細を入力する際には、次のヒントが役立つ場合があります。

    • 事前定義された値を使用してコンソールのフィールドに自動的に値を入力する場合は、ホストインベントリーの認証情報を作成できます。詳細は、オンプレミス環境の認証情報の作成 を参照してください。
    • Cluster details ページのプルシークレットは、OpenShift Container Platform リソースへのアクセスに使用する OpenShift Container Platform プルシークレットです。ホストインベントリー認証情報を選択した場合は、プルシークレットが自動的に入力されます。
    • Node pools ページでは、namespace にノードプールのホストが含まれます。コンソールを使用してホストインベントリーを作成した場合、コンソールは専用の namespace を作成します。
    • Networking ページで、API サーバー公開ストラテジーを選択します。ホステッドクラスターの API サーバーは、既存のロードバランサーを使用するか、NodePort タイプのサービスとして公開できます。API サーバーに到達できる宛先を指す api.${HOSTED_CLUSTER_NAME}.${BASEDOMAIN} 設定に DNS エントリーを含める必要があります。このエントリーとして、管理クラスター内のノードの 1 つを指すレコード、または受信トラフィックを Ingress Pod にリダイレクトするロードバランサーを指すレコードを指定できます。

  6. エントリーを確認し、Create をクリックします。

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

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

ミラーレジストリーを使用して、hcp create cluster コマンドで --image-content-sources フラグを指定して、ベアメタル上にホステッドクラスターを作成できます。以下の手順を実行します。

  1. YAML ファイルを作成して、イメージコンテンツソースポリシー (ICSP) を定義します。以下の例を参照してください。 

    - mirrors:
  - brew.registry.redhat.io
  source: registry.redhat.io
- mirrors:
  - brew.registry.redhat.io
  source: registry.stage.redhat.io
- mirrors:
  - brew.registry.redhat.io
  source: registry-proxy.engineering.redhat.com
  2. ファイルを icsp.yaml として保存します。このファイルにはミラーレジストリーが含まれます。

  3. ミラーレジストリーを使用してホステッドクラスターを作成するには、次のコマンドを実行します。 

    hcp create cluster agent \
    --name=<hosted_cluster_name> \ 1
    --pull-secret=<path_to_pull_secret> \ 2
    --agent-namespace=<hosted_control_plane_namespace> \ 3
    --base-domain=<basedomain> \ 4
    --api-server-address=api.<hosted_cluster_name>.<basedomain> \
    --image-content-sources icsp.yaml  \ 5
    --ssh-key  <path_to_ssh_key> \ 6
    --namespace <hosted_cluster_namespace> \ 7
    --release-image=quay.io/openshift-release-dev/ocp-release:<ocp_release_image> 8
    1
    ホステッドクラスターの名前を指定します (例: example)。
    2
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    3
    Hosted Control Plane namespace を指定します (例: clusters-example)。oc get agent -n <hosted-control-plane-namespace> コマンドを使用して、この namespace でエージェントが使用可能であることを確認します。
    4
    ベースドメインを指定します (例: krnl.es)。
    5
    ICSP およびミラーレジストリーを定義する icsp.yaml ファイルを指定します。
    6
    SSH 公開鍵へのパスを指定します。デフォルトのファイルパスは ~/.ssh/id_rsa.pub です。
    7
    ホストされたクラスターの namespace を指定します。
    8
    使用するサポートされている OpenShift Container Platform のバージョンを指定します (例: 4.14.0-x86_64)。非接続環境を使用している場合は、<ocp_release_image> をダイジェストイメージに置き換えます。OpenShift Container Platform リリースイメージダイジェストを抽出するには、OpenShift Container Platform リリースイメージダイジェストの抽出 を参照してください。
1.7.7.5.3. 関連情報

1.7.7.6. ホステッドクラスター作成の確認

デプロイメントプロセスが完了したら、ホステッドクラスターが正常に作成されたことを確認できます。ホステッドクラスターの作成から数分後に、次の手順に従います。

  1. 次の extract コマンドを入力して、新しいホステッドクラスターの kubeconfig を取得します。 

    oc extract -n <hosted-control-plane-namespace> secret/admin-kubeconfig --to=- > kubeconfig-<hosted-cluster-name>

  2. kubeconfig を使用して、ホステッドクラスターのクラスター Operator を表示します。以下のコマンドを入力します。 

    oc get co --kubeconfig=kubeconfig-<hosted-cluster-name>

    以下の出力例を参照してください。 

    NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
console                                    4.10.26   True        False         False      2m38s
dns                                        4.10.26   True        False         False      2m52s
image-registry                             4.10.26   True        False         False      2m8s
ingress                                    4.10.26   True        False         False      22m

  3. 次のコマンドを入力して、ホステッドクラスター上で実行中の Pod を表示することもできます。 

    oc get pods -A --kubeconfig=kubeconfig-<hosted-cluster-name>

    以下の出力例を参照してください。 

    NAMESPACE                                          NAME                                                      READY   STATUS             RESTARTS        AGE
kube-system                                        konnectivity-agent-khlqv                                  0/1     Running            0               3m52s
openshift-cluster-node-tuning-operator             tuned-dhw5p                                               1/1     Running            0               109s
openshift-cluster-storage-operator                 cluster-storage-operator-5f784969f5-vwzgz                 1/1     Running            1 (113s ago)    20m
openshift-cluster-storage-operator                 csi-snapshot-controller-6b7687b7d9-7nrfw                  1/1     Running            0               3m8s
openshift-console                                  console-5cbf6c7969-6gk6z                                  1/1     Running            0               119s
openshift-console                                  downloads-7bcd756565-6wj5j                                1/1     Running            0               4m3s
openshift-dns-operator                             dns-operator-77d755cd8c-xjfbn                             2/2     Running            0               21m
openshift-dns                                      dns-default-kfqnh                                         2/2     Running            0               113s

1.7.7.7. ホステッドクラスターの NodePool オブジェクトのスケーリング

ホストされたクラスターにノードを追加することで、NodePool オブジェクトをスケールアップできます。

  1. NodePool オブジェクトを 2 つのノードにスケーリングします。 

    oc -n <hosted-cluster-namespace> scale nodepool <nodepool-name> --replicas 2

    Cluster API エージェントプロバイダーは、ホステッドクラスターに割り当てられる 2 つのエージェントをランダムに選択します。これらのエージェントはさまざまな状態を経て、最終的に OpenShift Container Platform ノードとしてホステッドクラスターに参加します。エージェントは次の順序で状態を通過します。

    • binding
    • discovering
    • insufficient
    • installing
    • installing-in-progress
    • added-to-existing-cluster

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

    oc -n <hosted-control-plane-namespace> get agent

    以下の出力例を参照してください。 

    NAME                                   CLUSTER         APPROVED   ROLE          STAGE
4dac1ab2-7dd5-4894-a220-6a3473b67ee6   hypercluster1   true       auto-assign
d9198891-39f4-4930-a679-65fb142b108b                   true       auto-assign
da503cf1-a347-44f2-875c-4960ddb04091   hypercluster1   true       auto-assign

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

    oc -n <hosted-control-plane-namespace> get agent -o jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}'

    以下の出力例を参照してください。 

    BMH: ocp-worker-2 Agent: 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 State: binding
BMH: ocp-worker-0 Agent: d9198891-39f4-4930-a679-65fb142b108b State: known-unbound
BMH: ocp-worker-1 Agent: da503cf1-a347-44f2-875c-4960ddb04091 State: insufficient

  4. 次の extract コマンドを入力して、新しいホステッドクラスターの kubeconfig を取得します。 

    oc extract -n <hosted-cluster-namespace> secret/<hosted-cluster-name>-admin-kubeconfig --to=- > kubeconfig-<hosted-cluster-name>

  5. エージェントが added-to-existing-cluster 状態に達したら、次のコマンドを入力して、ホステッドクラスターの OpenShift Container Platform ノードが表示されることを確認します。 

    oc --kubeconfig kubeconfig-<hosted-cluster-name> get nodes

    以下の出力例を参照してください。 

    NAME           STATUS   ROLES    AGE     VERSION
ocp-worker-1   Ready    worker   5m41s   v1.24.0+3882f8f
ocp-worker-2   Ready    worker   6m3s    v1.24.0+3882f8f

    Cluster Operator は、ワークロードをノードに追加することによって調整を開始します。

  6. 次のコマンドを入力して、NodePool オブジェクトをスケールアップしたときに 2 台のマシンが作成されたことを確認します。 

    oc -n <hosted-control-plane-namespace> get machines

    以下の出力例を参照してください。 

    NAME                            CLUSTER               NODENAME       PROVIDERID                                     PHASE     AGE   VERSION
hypercluster1-c96b6f675-m5vch   hypercluster1-b2qhl   ocp-worker-1   agent://da503cf1-a347-44f2-875c-4960ddb04091   Running   15m   4.13z
hypercluster1-c96b6f675-tl42p   hypercluster1-b2qhl   ocp-worker-2   agent://4dac1ab2-7dd5-4894-a220-6a3473b67ee6   Running   15m   4.13z

    clusterversion 調整プロセスは最終的に、Ingress および Console クラスター Operator のみが欠落しているポイントに到達します。

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

    oc --kubeconfig kubeconfig-<hosted-cluster-name> get clusterversion,co

    以下の出力例を参照してください。 

    NAME                                         VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
clusterversion.config.openshift.io/version             False       True          40m     Unable to apply 4.13z: the cluster operator console has not yet successfully rolled out

NAME                                                                           VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
clusteroperator.config.openshift.io/console                                    4.12z    False       False         False      11m     RouteHealthAvailable: failed to GET route (https://console-openshift-console.apps.hypercluster1.domain.com): Get "https://console-openshift-console.apps.hypercluster1.domain.com": dial tcp 10.19.3.29:443: connect: connection refused
clusteroperator.config.openshift.io/csi-snapshot-controller                    4.12z    True        False         False      10m
clusteroperator.config.openshift.io/dns                                        4.12z    True        False         False      9m16s
1.7.7.7.1. ノードプールの追加

名前、レプリカの数、およびエージェントラベルセレクターなどの追加情報を指定して、ホステッドクラスターのノードプールを作成できます。

  1. ノードプールを作成するには、次の情報を入力します。 

    export NODEPOOL_NAME=${CLUSTER_NAME}-extra-cpu
export WORKER_COUNT="2"

hcp create nodepool agent \
  --cluster-name $CLUSTER_NAME \
  --name $NODEPOOL_NAME \
  --node-count $WORKER_COUNT \
  --agentLabelSelector '{"matchLabels": {"size": "medium"}}' 1
    1
    --agentLabelSelector は任意です。ノードプールは、"size" : "medium" ラベルを持つエージェントを使用します。

  2. clusters namespace 内のノードプールリソースをリストして、nodepool プールのステータスを確認します。 

    oc get nodepools --namespace clusters

  3. 次のコマンドを入力して、admin-kubeconfig シークレットを抽出します。 

    oc extract -n <hosted-control-plane-namespace> secret/admin-kubeconfig --to=./hostedcluster-secrets --confirm

    以下の出力例を参照してください。 

    hostedcluster-secrets/kubeconfig

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

    oc --kubeconfig ./hostedcluster-secrets get nodes

  5. 次のコマンドを入力して、使用可能なノードプールの数が予想されるノードプールの数と一致することを確認します。 

    oc get nodepools --namespace clusters
1.7.7.7.2. 関連情報

1.7.7.8. ベアメタル上のホステッドクラスターでの Ingress の処理

すべての OpenShift Container Platform クラスターには、通常、外部 DNS レコードが関連付けられているデフォルトのアプリケーション Ingress コントローラーがあります。たとえば、ベースドメイン krnl.es で example という名前のホストされたクラスターを作成する場合は、ワイルドカードドメイン *.apps.example.krnl.es がルーティング可能であると予想することができます。

*.apps ドメインのロードバランサーとワイルドカード DNS レコードを設定するには、ゲストクラスターで次のアクションを実行します。

  1. MetalLB Operator の設定を含む YAML ファイルを作成して MetalLB をデプロイします。 

    apiVersion: v1
kind: Namespace
metadata:
  name: metallb
  labels:
    openshift.io/cluster-monitoring: "true"
  annotations:
    workload.openshift.io/allowed: management
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: metallb-operator-operatorgroup
  namespace: metallb
---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: metallb-operator
  namespace: metallb
spec:
  channel: "stable"
  name: metallb-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  2. ファイルを metallb-operator-config.yaml として保存します。

  3. 以下のコマンドを入力して設定を適用します。 

    oc apply -f metallb-operator-config.yaml

  4. Operator の実行後、MetalLB インスタンスを作成します。

    1. MetalLB インスタンスの設定を含む YAML ファイルを作成します。 

      apiVersion: metallb.io/v1beta1
kind: MetalLB
metadata:
  name: metallb
  namespace: metallb
    2. ファイルを metallb-instance-config.yaml として保存します。
    3. 次のコマンドを入力して、MetalLB インスタンスを作成します。 
    oc apply -f metallb-instance-config.yaml

  5. 2 つのリソースを作成して MetalLB Operator を設定します。

    • 単一の IP アドレスを持つ IPAddressPool リソース。この IP アドレスは、クラスターノードが使用するネットワークと同じサブネット上にある必要があります。

    • IPAddressPool リソースが BGP プロトコルを通じて提供するロードバランサーの IP アドレスをアドバタイズするための BGP アドバタイズリソース。

      1. 設定を含む YAML ファイルを作成します。 
    apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: <ip_address_pool_name> 1
  namespace: metallb
spec:
  protocol: layer2
  autoAssign: false
  addresses:
    - <ingress_ip>-<ingress_ip> 2
---
apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:
  name: <bgp_advertisement_name> 3
  namespace: metallb
spec:
  ipAddressPools:
    - <ip_address_pool_name> 4
1 4
IPAddressPool リソース名を指定します。
2
環境の IP アドレスを指定します (例: 192.168.122.23)。
3
BGPAdvertisement リソース名を指定します。
  1. ファイルを ipaddresspool-bgpadvertisement-config.yaml として保存します。

  2. 次のコマンドを入力してリソースを作成します。 

    oc apply -f ipaddresspool-bgpadvertisement-config.yaml
    1. LoadBalancer タイプのサービスを作成すると、MetalLB はサービスに外部 IP アドレスを追加します。

  3. metallb-loadbalancer-service.yaml という名前の YAML ファイルを作成して、Ingress トラフィックを Ingress デプロイメントにルーティングする新しいロードバランサーサービスを設定します。 

    kind: Service
apiVersion: v1
metadata:
  annotations:
    metallb.universe.tf/address-pool: ingress-public-ip
  name: metallb-ingress
  namespace: openshift-ingress
spec:
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 80
    - name: https
      protocol: TCP
      port: 443
      targetPort: 443
  selector:
    ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default
  type: LoadBalancer
  4. metallb-loadbalancer-service.yaml ファイルを保存します。

  5. YAML 設定を適用するには、次のコマンドを入力します。 

    oc apply -f metallb-loadbalancer-service.yaml

  6. 次のコマンドを入力して、OpenShift Container Platform コンソールにアクセスします。 

    curl -kI https://console-openshift-console.apps.example.krnl.es

HTTP/1.1 200 OK

  7. clusterversion と clusteroperator の値をチェックして、すべてが実行されていることを確認します。以下のコマンドを入力します。 

    oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusterversion,co

    以下の出力例を参照してください。 

NAME                                         VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
clusterversion.config.openshift.io/version   4.x.y      True        False         3m32s   Cluster version is 4.x.y

NAME                                                                           VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
clusteroperator.config.openshift.io/console                                    4.x.y     True        False         False      3m50s
clusteroperator.config.openshift.io/ingress                                    4.x.y     True        False         False      53m

+ 4.x.y は、使用する OpenShift Container Platform サポート対象バージョン (例: 4.14.0-x86_64 に置き換えます。

1.7.7.8.1. 関連情報

1.7.7.9. ホステッドクラスターのノード自動スケーリングの有効化

ホステッドクラスターにさらに容量が必要で、予備のエージェントが利用可能な場合は、自動スケーリングを有効にして新しいワーカーノードをインストールできます。

  1. 自動スケーリングを有効にするには、次のコマンドを入力します。 

    oc -n <hosted-cluster-namespace> patch nodepool <hosted-cluster-name> --type=json -p '[{"op": "remove", "path": "/spec/replicas"},{"op":"add", "path": "/spec/autoScaling", "value": { "max": 5, "min": 2 }}]'

注記: この例では、ノードの最小数は 2、最大数は 5 です。追加できるノードの最大数は、プラットフォームによって制限される場合があります。たとえば、エージェントプラットフォームを使用する場合、ノードの最大数は使用可能なエージェントの数によって制限されます。

  1. 新しいノードを必要とするワークロードを作成します。

    1. 次の例を使用して、ワークロード設定を含む YAML ファイルを作成します。 

      apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: reversewords
  name: reversewords
  namespace: default
spec:
  replicas: 40
  selector:
    matchLabels:
      app: reversewords
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: reversewords
  spec:
    containers:
    - image: quay.io/mavazque/reversewords:latest
      name: reversewords
      resources:
        requests:
          memory: 2Gi
status: {}
    2. ファイルを workload-config.yaml として保存します。
    3. 以下のコマンドを入力して、YAML を適用します。 
    oc apply -f workload-config.yaml

  2. 次のコマンドを入力して、admin-kubeconfig シークレットを抽出します。 

    oc extract -n <hosted-cluster-namespace> secret/<hosted-cluster-name>-admin-kubeconfig --to=./hostedcluster-secrets --confirm

    以下の出力例を参照してください。 

    hostedcluster-secrets/kubeconfig

  3. 次のコマンドを入力して、新しいノードが Ready ステータスであるかどうかを確認できます。 

    oc --kubeconfig ./hostedcluster-secrets get nodes

  4. ノードを削除するには、次のコマンドを入力してワークロードを削除します。 

    oc --kubeconfig ./hostedcluster-secrets -n default delete deployment reversewords

  5. 数分間待ちます。その間に、容量の追加が必要にならないようにします。エージェントプラットフォームでは、エージェントは廃止され、再利用できます。次のコマンドを入力すると、ノードが削除されたことを確認できます。 

    oc --kubeconfig ./hostedcluster-secrets get nodes
1.7.7.9.1. ホストされたクラスターのノードの自動スケーリングを無効にする

ノードの自動スケーリングを無効にするには、次のコマンドを入力します。 

oc -n <hosted-cluster-namespace> patch nodepool <hosted-cluster-name> --type=json -p '[\{"op":"remove", "path": "/spec/autoScaling"}, \{"op": "add", "path": "/spec/replicas", "value": <specify-value-to-scale-replicas>]'

このコマンドは、YAML ファイルから "spec.autoScaling" を削除し、"spec.replicas" を追加し、"spec.replicas" を指定の整数値に設定します。

1.7.7.10. ベアメタルでのホステッドクラスターの破棄

コンソールを使用して、ベアメタルホステッドクラスターを破棄できます。ベアメタル上のホステッドクラスターを破壊するには、次の手順を実行します。

  1. コンソールで、Infrastructure > Clusters に移動します。
  2. Clusters ページで、破棄するクラスターを選択します。
  3. Actions メニューで Destroy clusters を選択し、クラスターを削除します。
1.7.7.10.1. コマンドラインを使用したベアメタル上でのホステッドクラスターの破棄

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

  • 次のコマンドを実行して、ホステッドクラスターとそのバックエンドリソースを削除します。 

    hcp destroy cluster agent --name <hosted_cluster_name>

    <hosted_cluster_name> をホストされたクラスターの名前に置き換えます。

1.7.8. 非ベアメタルエージェントマシンを使用した Hosted Control Plane クラスターの設定 (テクノロジープレビュー)

ホスティングクラスターとして機能するようにクラスターを設定することで、Hosted Control Plane をデプロイメントできます。ホスティングクラスターは、コントロールプレーンがホストされる OpenShift Container Platform クラスターです。ホスティングクラスターは 管理 クラスターとも呼ばれます。

注記: 管理クラスターは、マネージド クラスターとは異なります。マネージドクラスターは、ハブクラスターが管理するクラスターです。

Hosted Control Plane 機能がデフォルトで有効になりました。

マルチクラスターエンジン Operator 2.5 は、管理対象のハブクラスターであるデフォルトの local-cluster と、ホスティングクラスターとしてのハブクラスターのみをサポートします。Red Hat Advanced Cluster Management 2.10 では、マネージドハブクラスター (local-cluster) をホスティングクラスターとして使用できます。

ホストされたクラスター は、ホスティングクラスターでホストされる API エンドポイントとコントロールプレーンを含む OpenShift Container Platform クラスターです。ホステッドクラスターには、コントロールプレーンとそれに対応するデータプレーンが含まれます。マルチクラスターエンジンの Operator コンソールまたは Hosted Control Plane のコマンドラインインターフェイス hcp を使用して、ホステッドクラスターを作成できます。ホステッドクラスターは、マネージドクラスターとして自動的にインポートされます。この自動インポート機能を無効にする場合は、マルチクラスターエンジン Operator へのホストクラスターの自動インポートの無効化 を参照してください。

重要:

  • 各ホステッドクラスターに、クラスター全体で一意の名前が必要です。マルチクラスターエンジン Operator によってホストクラスターを管理するには、ホストクラスター名を既存のマネージドクラスターと同じにすることはできません。
  • ホステッドクラスター名として clusters を使用しないでください。
  • Hosted Control Plane の同じプラットフォームで、ハブクラスターとワーカーを実行します。
  • ホステッドクラスターは、マルチクラスターエンジンの operator 管理クラスターの namespace には作成できません。
  • エージェントプラットフォームを使用して、エージェントマシンをワーカーノードとしてホステッドクラスターに追加できます。エージェントマシンは、Discovery Image でブートされ、OpenShift Container Platform ノードとしてプロビジョニングされる準備ができているホストを表します。Agent プラットフォームは、Central Infrastructure Management サービスの一部です。詳細は、Central Infrastructure Management サービスの有効化 を参照してください。
  • ベアメタルではないすべてのホストは、Central Infrastructure Management が提供する Discovery Image ISO を使用して手動でブートする必要があります。
  • Agent プラットフォームでホステッドクラスターを作成すると、HyperShift は Hosted Control Plane namespace に Agent Cluster API プロバイダーをインストールします。
  • ノードプールをスケールアップすると、レプリカごとにマシンが作成されます。Cluster API プロバイダーは、マシンごとに、承認済みで、検証に合格し、現在使用されておらず、ノードプール仕様で指定されている要件を満たしているエージェントを検索してインストールします。エージェントのステータスと状態を確認することで、エージェントのインストールを監視できます。
  • ノードプールをスケールダウンすると、エージェントは対応するクラスターからバインド解除されます。Agent を再利用するには、Discovery イメージを使用してエージェントを再起動する必要があります。
  • Hosted Control Plane のストレージを設定する場合は、etcd の推奨プラクティスを考慮してください。レイテンシー要件を満たすには、各コントロールプレーンノードで実行されるすべての Hosted Control Plane の etcd インスタンス専用の高速ストレージデバイスを使用します。LVM ストレージを使用して、ホストされた etcd Pod のローカルストレージクラスを設定できます。詳細は、OpenShift Container Platform ドキュメントの 推奨される etcd プラクティス および 論理ボリュームマネージャーストレージを使用した永続ストレージ を参照してください。

1.7.8.1. 前提条件

ホスティングクラスターを設定するには、次の前提条件を満たす必要があります。

  • OpenShift Container Platform クラスターにインストールされた Kubernetes Operator 2.5 以降のマルチクラスターエンジン。マルチクラスターエンジン Operator は、Red Hat Advanced Cluster Management をインストールすると自動的にインストールされます。OpenShift Container Platform OperatorHub から Operator として Red Hat Advanced Cluster Management を使用せずに、マルチクラスターエンジン Operator をインストールすることもできます。

  • マルチクラスターエンジン Operator には、少なくとも 1 つのマネージド OpenShift Container Platform クラスターが必要です。local-cluster は自動的にインポートされます。local-cluster の詳細については、詳細設定 を参照してください。次のコマンドを実行して、ハブクラスターの状態を確認できます。 

    oc get managedclusters local-cluster
  • Central Infrastructure Management を有効にする必要があります。詳細は、Central Infrastructure Management サービスの有効化 を参照してください。
  • Hosted Control Plane コマンドラインインターフェイスをインストールする 必要があります。

1.7.8.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 アドレスによるアクセスを簡素化します。

1.7.8.3. 非ベアメタルエージェントマシンのインフラストラクチャー要件

エージェントプラットフォームはインフラストラクチャーを作成しませんが、インフラストラクチャーに関して次の要件があります。

  • Agents: Agent は Discovery イメージで起動され、OpenShift Container Platform ノードとしてプロビジョニングする準備ができているホストを表します。
  • DNS: API および Ingress エンドポイントは、ルーティング可能である必要があります。

1.7.8.4. 非ベアメタルエージェントマシンでの DNS の設定

ホステッドクラスターの API サーバーは、NodePort サービスとして公開されます。API サーバーに到達できる宛先を指す api.<hosted-cluster-name>.<basedomain> に、DNS エントリーが存在する必要があります。

DNS エントリーは、Hosted Control Plane を実行しているマネージドクラスター内のノードの 1 つを指すレコードと同様、単純化できます。エントリーは、受信トラフィックを Ingress Pod にリダイレクトするためにデプロイされるロードバランサーを指すこともできます。

  • 次の DNS 設定の例を参照してください。 

    api-int.example.krnl.es.    IN A 192.168.122.22
`*`.apps.example.krnl.es. IN A 192.168.122.23

  • IPv6 ネットワークで非接続環境の DNS を設定する場合は、次の DNS 設定の例を参照してください。 

    api-int.example.krnl.es.    IN A 2620:52:0:1306::7
`*`.apps.example.krnl.es. IN A 2620:52:0:1306::10

  • デュアルスタックネットワークの非接続環境で DNS を設定する場合は、IPv4 と IPv6 の両方の DNS エントリーを含めるようにしてください。次の DNS 設定の例を参照してください。 

    host-record=api-int.hub-dual.dns.base.domain.name,2620:52:0:1306::2
address=/apps.hub-dual.dns.base.domain.name/2620:52:0:1306::3
dhcp-host=aa:aa:aa:aa:10:01,ocp-master-0,[2620:52:0:1306::5]

1.7.8.5. 非ベアメタルエージェントマシンでのホステッドクラスターの作成

ホステッドクラスターの作成やインポートが可能です。ホステッドクラスターをインポートする手順は、ホステッドクラスターのインポート を参照してください。

  1. 次のコマンドを入力して、Hosted Control Plane namespace を作成します。 

    oc create ns <hosted-cluster-namespace>-<hosted-cluster-name>

    <hosted-cluster-namespace> を、ホストされたクラスターの namespace 名 (例: clusters) に置き換えます。<hosted-cluster-name> をホストされたクラスター名に置き換えます。

  2. クラスターにデフォルトのストレージクラスが設定されていることを確認します。設定されていない場合は、PVC が保留になる可能性があります。次のコマンドを入力し、変数例を実際の情報に置き換えます。 

    hcp create cluster agent \
    --name=<hosted-cluster-name> \ 1
    --pull-secret=<path-to-pull-secret> \ 2
    --agent-namespace=<hosted-control-plane-namespace> \ 3
    --base-domain=<basedomain> \ 4
    --api-server-address=api.<hosted-cluster-name>.<basedomain> \
    --etcd-storage-class=<etcd-storage-class> \ 5
    --ssh-key  <path-to-ssh-key> \ 6
    --namespace <hosted-cluster-namespace> \ 7
    --control-plane-availability-policy SingleReplica \
    --release-image=quay.io/openshift-release-dev/ocp-release:<ocp-release> 8
    1
    ホステッドクラスターの名前を指定します (例: example)。
    2
    プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
    3
    Hosted Control Plane namespace を指定します (例: clusters-example)。oc get agent -n <hosted-control-plane-namespace> コマンドを使用して、この namespace でエージェントが使用可能であることを確認します。
    4
    ベースドメインを指定します (例: krnl.es)。
    5
    etcd ストレージクラス名を指定します (例: lvm-storageclass)。
    6
    SSH 公開鍵へのパスを指定します。デフォルトのファイルパスは ~/.ssh/id_rsa.pub です。
    7
    ホストされたクラスターの namespace を指定します。
    8
    使用するサポートされている OpenShift Container Platform のバージョンを指定します (例: 4.14.0-x86_64)。

  3. しばらくしてから、次のコマンドを入力して、Hosted Control Plane の Pod が稼働中であることを確認します。 

    oc -n <hosted-control-plane-namespace> get pods

    以下の出力例を参照してください。 

    NAME                                             READY   STATUS    RESTARTS   AGE
catalog-operator-6cd867cc7-phb2q                 2/2     Running   0          2m50s
control-plane-operator-f6b4c8465-4k5dh           1/1     Running   0          4m32s
1.7.8.5.1. コンソールを使用した非ベアメタルエージェントマシンでのホステッドクラスターの作成
  1. OpenShift Container Platform Web コンソールを開き、管理者の認証情報を入力してログインします。コンソールを開く手順については、OpenShift Container Platform ドキュメントの Web コンソールへのアクセス を参照してください。
  2. コンソールヘッダーで、All Clusters が選択されていることを確認します。
  3. Infrastructure > Clusters をクリックします。

  4. Create cluster Host inventory > Hosted control plane をクリックします。

    Create cluster ページが表示されます。

  5. Create cluster ページでプロンプトに従い、クラスター、ノードプール、ネットワーク、および自動化に関する詳細を入力します。

    注: クラスターに関する詳細を入力する際には、次のヒントが役立つ場合があります。

    • 事前定義された値を使用してコンソールのフィールドに自動的に値を入力する場合は、ホストインベントリーの認証情報を作成できます。詳細は、オンプレミス環境の認証情報の作成 を参照してください。
    • Cluster details ページのプルシークレットは、OpenShift Container Platform リソースへのアクセスに使用する OpenShift Container Platform プルシークレットです。ホストインベントリー認証情報を選択した場合は、プルシークレットが自動的に入力されます。
    • Node pools ページでは、namespace にノードプールのホストが含まれます。コンソールを使用してホストインベントリーを作成した場合、コンソールは専用の namespace を作成します。
    • Networking ページで、API サーバー公開ストラテジーを選択します。ホステッドクラスターの API サーバーは、既存のロードバランサーを使用するか、NodePort タイプのサービスとして公開できます。API サーバーに到達できる宛先を指す api.${HOSTED_CLUSTER_NAME}.${BASEDOMAIN} 設定に DNS エントリーを含める必要があります。このエントリーとして、管理クラスター内のノードの 1 つを指すレコード、または受信トラフィックを Ingress Pod にリダイレクトするロードバランサーを指すレコードを指定できます。

  6. エントリーを確認し、Create をクリックします。

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

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

1.7.8.6. ホステッドクラスター作成の確認

デプロイメントプロセスが完了したら、ホステッドクラスターが正常に作成されたことを確認できます。ホステッドクラスターの作成から数分後に、次の手順に従います。

  1. 次の extract コマンドを入力して、新しいホステッドクラスターの kubeconfig を取得します。 

    oc extract -n <hosted-cluster-namespace> secret/<hosted-cluster-name>-admin-kubeconfig --to=- > kubeconfig-<hosted-cluster-name>

  2. kubeconfig を使用して、ホステッドクラスターのクラスター Operator を表示します。以下のコマンドを入力します。 

    oc get co --kubeconfig=kubeconfig-<hosted_cluster_name>

    以下の出力例を参照してください。 

    NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
console                                    4.10.26   True        False         False      2m38s
csi-snapshot-controller                    4.10.26   True        False         False      4m3s
dns                                        4.10.26   True        False         False      2m52s

  3. 次のコマンドを入力して、ホステッドクラスター上で実行中の Pod を表示することもできます。 

    oc get pods -A --kubeconfig=kubeconfig-<hosted-cluster-name>

    以下の出力例を参照してください。 

    NAMESPACE                                          NAME                                                      READY   STATUS             RESTARTS        AGE
kube-system                                        konnectivity-agent-khlqv                                  0/1     Running            0               3m52s
openshift-cluster-samples-operator                 cluster-samples-operator-6b5bcb9dff-kpnbc                 2/2     Running            0               20m
openshift-monitoring                               alertmanager-main-0                                       6/6     Running            0               100s
openshift-monitoring                               openshift-state-metrics-677b9fb74f-qqp6g                  3/3     Running            0               104s

1.7.8.7. ホステッドクラスターの NodePool オブジェクトのスケーリング

NodePool オブジェクトをスケーリングして、ホステッドクラスターにノードを追加します。

  1. NodePool オブジェクトを 2 つのノードにスケーリングします。 

    oc -n <hosted-cluster-namespace> scale nodepool <nodepool-name> --replicas 2

    Cluster API エージェントプロバイダーは、ホステッドクラスターに割り当てられる 2 つのエージェントをランダムに選択します。これらのエージェントはさまざまな状態を経て、最終的に OpenShift Container Platform ノードとしてホステッドクラスターに参加します。エージェントは次の順序で状態を通過します。

    • binding
    • discovering
    • insufficient
    • installing
    • installing-in-progress
    • added-to-existing-cluster

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

    oc -n <hosted-control-plane-namespace> get agent

    以下の出力例を参照してください。 

    NAME                                   CLUSTER         APPROVED   ROLE          STAGE
4dac1ab2-7dd5-4894-a220-6a3473b67ee6   hypercluster1   true       auto-assign

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

    oc -n <hosted-control-plane-namespace> get agent -o jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}'

    以下の出力例を参照してください。 

    BMH: ocp-worker-2 Agent: 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 State: binding
BMH: ocp-worker-1 Agent: da503cf1-a347-44f2-875c-4960ddb04091 State: insufficient

  4. 次の extract コマンドを入力して、新しいホステッドクラスターの kubeconfig を取得します。 

    oc extract -n <hosted-cluster-namespace> secret/<hosted-cluster-name>-admin-kubeconfig --to=- > kubeconfig-<hosted-cluster-name>

  5. エージェントが added-to-existing-cluster 状態に達したら、次のコマンドを入力して、ホステッドクラスターの OpenShift Container Platform ノードが表示されることを確認します。 

    oc --kubeconfig kubeconfig-<hosted-cluster-name> get nodes

    以下の出力例を参照してください。 

    NAME           STATUS   ROLES    AGE     VERSION
ocp-worker-1   Ready    worker   5m41s   v1.24.0+3882f8f

    Cluster Operator は、ワークロードをノードに追加することによって調整を開始します。

  6. 次のコマンドを入力して、NodePool オブジェクトをスケールアップしたときに 2 台のマシンが作成されたことを確認します。 

    oc -n <hosted-control-plane-namespace> get machines

    以下の出力例を参照してください。 

    NAME                            CLUSTER               NODENAME       PROVIDERID                                     PHASE     AGE   VERSION
hypercluster1-c96b6f675-m5vch   hypercluster1-b2qhl   ocp-worker-1   agent://da503cf1-a347-44f2-875c-4960ddb04091   Running   15m   4.13z

    clusterversion 調整プロセスは最終的に、Ingress および Console クラスター Operator のみが欠落しているポイントに到達します。

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

    oc --kubeconfig kubeconfig-<hosted-cluster-name> get clusterversion,co

    以下の出力例を参照してください。 

    NAME                                         VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
clusterversion.config.openshift.io/version             False       True          40m     Unable to apply 4.13z: the cluster operator console has not yet successfully rolled out

NAME                                                                           VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
clusteroperator.config.openshift.io/console                                    4.13z    False       False         False      11m     RouteHealthAvailable: failed to GET route (https://console-openshift-console.apps.hypercluster1.domain.com): Get "https://console-openshift-console.apps.hypercluster1.domain.com": dial tcp 10.19.3.29:443: connect: connection refused
clusteroperator.config.openshift.io/csi-snapshot-controller                    4.13z    True        False         False      10m
clusteroperator.config.openshift.io/dns                                        4.13z    True        False         False      9m16s
1.7.8.7.1. ノードプールの追加

名前、レプリカの数、およびエージェントラベルセレクターなどの追加情報を指定して、ホステッドクラスターのノードプールを作成できます。

  1. ノードプールを作成するには、次の情報を入力します。 

    export NODEPOOL_NAME=${CLUSTER_NAME}-extra-cpu
export WORKER_COUNT="2"

hcp create nodepool agent \
  --cluster-name $CLUSTER_NAME \
  --name $NODEPOOL_NAME \
  --node-count $WORKER_COUNT \
  --agentLabelSelector '{"matchLabels": {"size": "medium"}}' 1
    1
    --agentLabelSelector は任意です。ノードプールは、"size" : "medium" ラベルを持つエージェントを使用します。

  2. clusters namespace 内のノードプールリソースをリストして、nodepool プールのステータスを確認します。 

    oc get nodepools --namespace clusters

  3. 次のコマンドを入力して、admin-kubeconfig シークレットを抽出します。 

    oc extract -n <hosted-cluster-namespace> secret/<hosted-cluster-name>-admin-kubeconfig --to=./hostedcluster-secrets --confirm

    以下の出力例を参照してください。 

    hostedcluster-secrets/kubeconfig

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

    oc --kubeconfig ./hostedcluster-secrets get nodes

  5. 次のコマンドを入力して、使用可能なノードプールの数が予想されるノードプールの数と一致することを確認します。 

    oc get nodepools --namespace clusters
1.7.8.7.2. 関連情報

1.7.8.8. 非ベアメタルエージェントマシン上のホステッドクラスターでの Ingress の処理

すべての OpenShift Container Platform クラスターには、通常、外部 DNS レコードが関連付けられているデフォルトのアプリケーション Ingress コントローラーがあります。たとえば、ベースドメイン krnl.es で example という名前のホストされたクラスターを作成する場合は、ワイルドカードドメイン *.apps.example.krnl.es がルーティング可能であると予想することができます。

*.apps ドメインのロードバランサーとワイルドカード DNS レコードを設定するには、ゲストクラスターで次のアクションを実行します。

  1. MetalLB Operator の設定を含む YAML ファイルを作成して MetalLB をデプロイします。 

    apiVersion: v1
kind: Namespace
metadata:
  name: metallb
  labels:
    openshift.io/cluster-monitoring: "true"
  annotations:
    workload.openshift.io/allowed: management
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: metallb-operator-operatorgroup
  namespace: metallb
---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: metallb-operator
  namespace: metallb
spec:
  channel: "stable"
  name: metallb-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  2. ファイルを metallb-operator-config.yaml として保存します。

  3. 以下のコマンドを入力して設定を適用します。 

    oc apply -f metallb-operator-config.yaml

  4. Operator の実行後、MetalLB インスタンスを作成します。

    1. MetalLB インスタンスの設定を含む YAML ファイルを作成します。 

      apiVersion: metallb.io/v1beta1
kind: MetalLB
metadata:
  name: metallb
  namespace: metallb
    2. ファイルを metallb-instance-config.yaml として保存します。
    3. 次のコマンドを入力して、MetalLB インスタンスを作成します。 
    oc apply -f metallb-instance-config.yaml

  5. 2 つのリソースを作成して MetalLB Operator を設定します。

    • 単一の IP アドレスを持つ IPAddressPool リソース。この IP アドレスは、クラスターノードが使用するネットワークと同じサブネット上にある必要があります。

    • IPAddressPool リソースが BGP プロトコルを通じて提供するロードバランサーの IP アドレスをアドバタイズするための BGP アドバタイズリソース。

      1. 設定を含む YAML ファイルを作成します。 
    apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: <ip_address_pool_name> 1
  namespace: metallb
spec:
  protocol: layer2
  autoAssign: false
  addresses:
    - <ingress_ip>-<ingress_ip> 2
---
apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:
  name: <bgp_advertisement_name> 3
  namespace: metallb
spec:
  ipAddressPools:
    - <ip_address_pool_name> 4
1 4
IPAddressPool リソース名を指定します。
2
環境の IP アドレスを指定します (例: 192.168.122.23)。
3
BGPAdvertisement リソース名を指定します。
  1. ファイルを ipaddresspool-bgpadvertisement-config.yaml として保存します。

  2. 次のコマンドを入力してリソースを作成します。 

    oc apply -f ipaddresspool-bgpadvertisement-config.yaml
    1. LoadBalancer タイプのサービスを作成すると、MetalLB はサービスに外部 IP アドレスを追加します。

  3. metallb-loadbalancer-service.yaml という名前の YAML ファイルを作成して、Ingress トラフィックを Ingress デプロイメントにルーティングする新しいロードバランサーサービスを設定します。 

    kind: Service
apiVersion: v1
metadata:
  annotations:
    metallb.universe.tf/address-pool: ingress-public-ip
  name: metallb-ingress
  namespace: openshift-ingress
spec:
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 80
    - name: https
      protocol: TCP
      port: 443
      targetPort: 443
  selector:
    ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default
  type: LoadBalancer
  4. ファイルを metallb-loadbalancer-service.yaml として保存します。

  5. YAML 設定を適用するには、次のコマンドを入力します。 

    oc apply -f metallb-loadbalancer-service.yaml

  6. 次のコマンドを入力して、OpenShift Container Platform コンソールにアクセスします。 

    curl -kI https://console-openshift-console.apps.example.krnl.es

HTTP/1.1 200 OK

  7. clusterversion と clusteroperator の値をチェックして、すべてが実行されていることを確認します。以下のコマンドを入力します。 

    oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusterversion,co

    以下の出力例を参照してください。 

NAME                                         VERSION           AVAILABLE   PROGRESSING   SINCE   STATUS
clusterversion.config.openshift.io/version   4.x.y             True        False         3m32s   Cluster version is 4.x.y

NAME                                                                           VERSION           AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
clusteroperator.config.openshift.io/console                                    4.x.y             True        False         False      3m50s
clusteroperator.config.openshift.io/ingress                                    4.x.y             True        False         False      53m

+ 4.x.y は、使用する OpenShift Container Platform サポート対象バージョン (例: 4.14.0-x86_64 に置き換えます。

1.7.8.8.1. 関連情報

1.7.8.9. ホステッドクラスターのノード自動スケーリングの有効化

ホステッドクラスターにさらに容量が必要で、予備のエージェントが利用可能な場合は、自動スケーリングを有効にして新しいワーカーノードをインストールできます。

  1. 自動スケーリングを有効にするには、次のコマンドを入力します。この例では、ノードの最小数は 2 で、最大数は 5 です。追加できるノードの最大数は、プラットフォームによって制限される場合があります。たとえば、エージェントプラットフォームを使用する場合、ノードの最大数は使用可能なエージェントの数によって制限されます。 

    oc -n <hosted-cluster-namespace> patch nodepool <hosted-cluster-name> --type=json -p '[{"op": "remove", "path": "/spec/replicas"},{"op":"add", "path": "/spec/autoScaling", "value": { "max": 5, "min": 2 }}]'

  2. 新しいノードを必要とするワークロードを作成します。

    1. 次の例で使用して、ワークロード設定を含む YAML ファイルを作成します。 

      apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: reversewords
  name: reversewords
  namespace: default
spec:
  replicas: 40
  selector:
    matchLabels:
      app: reversewords
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: reversewords
  spec:
    containers:
    - image: quay.io/mavazque/reversewords:latest
      name: reversewords
      resources:
        requests:
          memory: 2Gi
status: {}
    2. ファイルを workload-config.yaml として保存します。
    3. 以下のコマンドを入力して、YAML を適用します。 
    oc apply -f workload-config.yaml

  3. 次のコマンドを入力して、admin-kubeconfig シークレットを抽出します。 

    oc extract -n <hosted-cluster-namespace> secret/<hosted-cluster-name>admin-kubeconfig --to=./hostedcluster-secrets --confirm

    以下の出力例を参照してください。 

    hostedcluster-secrets/kubeconfig

  4. 次のコマンドを入力して、新しいノードが Ready ステータスであるかどうかを確認できます。 

    oc --kubeconfig <hosted-cluster-name>.kubeconfig get nodes

  5. ノードを削除するには、次のコマンドを入力してワークロードを削除します。 

    oc --kubeconfig <hosted-cluster-name>.kubeconfig -n default delete deployment reversewords

  6. 数分間待ちます。その間に、容量の追加が必要にならないようにします。エージェントプラットフォームでは、エージェントは廃止され、再利用できます。次のコマンドを入力すると、ノードが削除されたことを確認できます。 

    oc --kubeconfig <hosted-cluster-name>.kubeconfig get nodes
1.7.8.9.1. ホストされたクラスターのノードの自動スケーリングを無効にする

ノードの自動スケーリングを無効にするには、次のコマンドを入力します。 

oc -n <hosted-cluster-namespace> patch nodepool <hosted-cluster-name> --type=json -p '[\{"op":"remove", "path": "/spec/autoScaling"}, \{"op": "add", "path": "/spec/replicas", "value": <specify-value-to-scale-replicas>]'

このコマンドは、YAML ファイルから "spec.autoScaling" を削除し、"spec.replicas" を追加し、"spec.replicas" を指定の整数値に設定します。

1.7.8.10. 非ベアメタルエージェントマシン上のホステッドクラスターの破棄

コンソールを使用して、非ベアメタルのホステッドクラスターを破棄できます。非ベアメタルエージェントマシン上のホステッドクラスターを破棄するには、次の手順を実行します。

  1. コンソールで、Infrastructure > Clusters に移動します。
  2. Clusters ページで、破棄するクラスターを選択します。
  3. Actions メニューで Destroy clusters を選択し、クラスターを削除します。
1.7.8.10.1. コマンドラインを使用した非ベアメタルエージェントマシン上のホステッドクラスターの破棄

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

  • 次のコマンドを実行して、ホステッドクラスターとそのバックエンドリソースを削除します。 

    hcp destroy cluster agent --name <hosted_cluster_name>

    <hosted_cluster_name> をホストされたクラスターの名前に置き換えます。

1.7.9. 64 ビット x86 OpenShift Container Platform クラスターでのホスティングクラスターの設定による、IBM Power コンピュートノードの Hosted Control Plane の作成 (テクノロジープレビュー)

テクノロジープレビュー: IBM Power (ppc64le) コンピュートノード用の 64 ビット x86 ベアメタル上でのホスティングクラスターの設定のサポートには制限があります。

ホスティングクラスターとして機能するようにクラスターを設定することで、Hosted Control Plane をデプロイメントできます。ホスティングクラスターは、コントロールプレーンがホストされる OpenShift Container Platform クラスターです。ホスティングクラスターは 管理 クラスターとも呼ばれます。

注:management クラスターは マネージド クラスターではありません。マネージドクラスターは、ハブクラスターが管理するクラスターです。

マルチクラスターエンジン Operator 2.5 は、管理対象のハブクラスターであるデフォルトの local-cluster と、ホスティングクラスターとしてのハブクラスターのみをサポートします。

重要:

  • エージェントプラットフォームを使用して、Hosted Control Plane をベアメタルでプロビジョニングできます。Agent プラットフォームは、Central Infrastructure Management サービスを使用して、ホステッドクラスターにワーカーノードを追加します。中央インフラストラクチャー管理サービスの概要については、ホストインベントリーの作成 を参照してください。
  • 各 IBM Power システムホストは、中央インフラストラクチャー管理が提供する Discovery イメージを使用して起動する必要があります。各ホストが起動すると、エージェントプロセスが実行されてホストの詳細が検出され、インストールが完了します。Agent カスタムリソースは、各ホストを表します。
  • Agent プラットフォームでホステッドクラスターを作成すると、HyperShift は Hosted Control Plane namespace に Agent Cluster API プロバイダーをインストールします。
  • ノードプールをスケールアップすると、マシンが作成されます。Cluster API プロバイダーは、承認され、検証に合格し、現在使用されておらず、ノードプールの仕様で指定されている要件を満たすエージェントを見つけます。エージェントのステータスと状態を確認することで、エージェントのインストールを監視できます。
  • ノードプールをスケールダウンすると、エージェントは対応するクラスターからバインド解除されます。クラスターを再利用する前に、Discovery イメージを使用してクラスターを再起動し、ノード数を更新する必要があります。

1.7.9.1. 前提条件

ホスティングクラスターを設定するには、次の前提条件を満たす必要があります。

  • OpenShift Container Platform クラスターにインストールされた Kubernetes Operator 2.5 以降のマルチクラスターエンジン。マルチクラスターエンジン Operator は、Red Hat Advanced Cluster Management をインストールすると自動的にインストールされます。OpenShift Container Platform OperatorHub から Operator として Red Hat Advanced Cluster Management を使用せずに、マルチクラスターエンジン Operator をインストールすることもできます。

  • マルチクラスターエンジン Operator には、少なくとも 1 つのマネージド OpenShift Container Platform クラスターが必要です。local-cluster は、マルチクラスターエンジン Operator 2.5 以降で自動的にインポートされます。local-cluster の詳細については、詳細設定 を参照してください。次のコマンドを実行して、ハブクラスターの状態を確認できます。 

    oc get managedclusters local-cluster
  • HyperShift Operator を実行するには、3 つ以上のワーカーノードを含むホスティングクラスターが必要です。
  • Central Infrastructure Management サービスが有効である。詳細は、Central Infrastructure Management サービスの有効化 を参照してください。
  • Hosted Control Plane コマンドラインインターフェイスをインストールする。Hosted Control Plane コマンドラインインターフェイスのインストール を参照してください。

1.7.9.2. IBM Power インフラストラクチャーの要件

エージェントプラットフォームはインフラストラクチャーを作成しませんが、インフラストラクチャーとして次のものが必要です。

  • Agents: Agent は Discovery イメージで起動され、OpenShift Container Platform ノードとしてプロビジョニングする準備ができているホストを表します。
  • DNS: API および Ingress エンドポイントは、ルーティング可能である必要があります。

1.7.9.3. IBM Power 設定ドキュメント

前提条件を満たしたら、次のトピックを参照して、ベアメタル上に Hosted Control Plane を設定します。

  1. InfraEnv リソースにエージェントを追加する
  2. IBM Power での Hosted Control Plane の DNS の設定
  3. ベアメタルでのホステッドクラスターの作成
  4. IBM Power コンピューティングノード用の 64 ビット x86 ベアメタル上への Hosted Control Plane 用の InfraEnv リソース作成
  5. IBM Power 上のホステッドクラスターの NodePool オブジェクトのスケーリング

1.7.9.4. InfraEnv リソースにエージェントを追加する

エージェントを追加するには、ライブ ISO で開始するようにマシンを手動で設定できます。

  1. ライブ ISO をダウンロードし、それを使用してホスト (ベアメタルまたは VM) を起動します。ライブ ISO の URL は、InfraEnv リソースの status.isoDownloadURL フィールドにあります。起動時に、ホストは Assisted Service と通信し、InfraEnv リソースと同じ namespace にエージェントとして登録します。

  2. エージェントとそのプロパティーの一部を一覧表示するには、次のコマンドを入力します。 

    oc -n <hosted-control-plane-namespace> get agents

    以下の出力例を参照してください。 

    NAME                                   CLUSTER   APPROVED   ROLE          STAGE
86f7ac75-4fc4-4b36-8130-40fa12602218                        auto-assign
e57a637f-745b-496e-971d-1abbf03341ba                        auto-assign

  3. 各エージェントが作成された後、オプションでその install_disk_id と hostname を仕様に設定し、次のコマンドを入力してエージェントを承認できます。 

    oc -n <hosted-control-plane-namespace> patch agent 86f7ac75-4fc4-4b36-8130-40fa12602218 -p '{"spec":{"installation_disk_id":"/dev/sda","approved":true,"hostname":"worker-0.example.krnl.es"}}' --type merge

oc -n <hosted-control-plane-namespace> patch agent 23d0c614-2caa-43f5-b7d3-0b3564688baa -p '{"spec":{"installation_disk_id":"/dev/sda","approved":true,"hostname":"worker-1.example.krnl.es"}}' --type merge

  4. エージェントの使用が承認されていることを確認するには、次のコマンドを入力して出力を確認します。 

    oc -n <hosted-control-plane-namespace> get agents

    以下の出力例を参照してください。 

    NAME                                   CLUSTER   APPROVED   ROLE          STAGE
86f7ac75-4fc4-4b36-8130-40fa12602218             true       auto-assign
e57a637f-745b-496e-971d-1abbf03341ba             true       auto-assign

1.7.9.5. IBM Power での Hosted Control Plane の DNS の設定

ホステッドクラスターの API サーバーが公開されます。API サーバーに到達可能な宛先を指す api.<hosted-cluster-name>.<base-domain> エントリーの DNS エントリーが存在する必要があります。

DNS エントリーは、Hosted Control Plane を実行しているマネージドクラスター内のノードの 1 つを指すレコードと同様、単純化できます。

エントリーは、受信トラフィックを Ingress Pod にリダイレクトするためにデプロイされるロードバランサーを指すこともできます。

次の DNS 設定例を参照してください。 

$ cat /var/named/<example.krnl.es.zone>

以下の出力例を参照してください。 

$ TTL 900
@ IN  SOA bastion.example.krnl.es.com. hostmaster.example.krnl.es.com. (
      2019062002
      1D 1H 1W 3H )
  IN NS bastion.example.krnl.es.com.
;
;
api                   IN A 1xx.2x.2xx.1xx 1
api-int               IN A 1xx.2x.2xx.1xx
;
;
*.apps.<hosted-cluster-name>.<basedomain>           IN A 1xx.2x.2xx.1xx
;
;EOF
1
このレコードは、Hosted Control Plane の受信トラフィックと送信トラフィックを処理する API ロードバランサーの IP アドレスを参照します。

IBM Power の場合、エージェントの IP アドレスに対応する IP アドレスを追加します。 

compute-0              IN A 1xx.2x.2xx.1yy
compute-1              IN A 1xx.2x.2xx.1yy

1.7.9.6. IBM Power コンピューティングノード用の 64 ビット x86 ベアメタル上への Hosted Control Plane 用の InfraEnv リソース作成

InfraEnv は、ライブ ISO を開始しているホストがエージェントとして参加できる環境です。この場合、エージェントは Hosted Control Plane と同じ namespace に作成されます。

InfraEnv リソースを作成するには、次の手順を実行します。

  1. 設定を含む YAML ファイルを作成します。以下の例を参照してください。 

    apiVersion: agent-install.openshift.io/v1beta1
kind: InfraEnv
metadata:
  name: <hosted-cluster-name>
  namespace: <hosted-control-plane-namespace>
spec:
  cpuArchitecture: ppc64le
  pullSecretRef:
    name: pull-secret
  sshAuthorizedKey: <ssh-public-key>
  2. ファイルを infraenv-config.yaml として保存します。

  3. 次のコマンドを入力して設定を適用します。 

    oc apply -f infraenv-config.yaml

  4. URL を取得してライブ ISO をダウンロードし、IBM Power マシンがエージェントとして参加できるようにするには、以下のコマンドを入力します。 

    oc -n <hosted-control-plane-namespace> get InfraEnv <hosted-cluster-name> -o json

1.7.9.7. IBM Power 上のホステッドクラスターの NodePool オブジェクトのスケーリング

NodePool オブジェクトは、ホステッドクラスターの作成時に作成されます。NodePool オブジェクトをスケーリングすることで、Hosted Control Plane にさらに多くのコンピュートノードを追加できます。

  1. 次のコマンドを実行して、NodePool オブジェクトを 2 つのノードにスケーリングします。 

    oc -n <clusters_namespace> scale nodepool <nodepool_name> --replicas 2

    Cluster API エージェントプロバイダーは、ホステッドクラスターに割り当てられる 2 つのエージェントをランダムに選択します。これらのエージェントはさまざまな状態を経て、最終的に OpenShift Container Platform ノードとしてホステッドクラスターに参加します。エージェントは次の順序で移行フェーズを通過します。

    • binding
    • discovering
    • insufficient
    • installing
    • installing-in-progress
    • added-to-existing-cluster

  2. 次のコマンドを実行して、スケールされた特定のエージェントのステータスを確認します。 

    oc -n <hosted_control_plane_namespace> get agent -o jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}'

    以下の出力を参照してください。 

    BMH: Agent: 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d State: known-unbound
BMH: Agent: 5e498cd3-542c-e54f-0c58-ed43e28b568a State: insufficient

  3. 次のコマンドを実行して、移行フェーズを表示します。 

    oc -n <hosted_control_plane_namespace> get agent

    以下の出力を参照してください。 

    NAME                                   CLUSTER           APPROVED       ROLE        STAGE
50c23cda-cedc-9bbd-bcf1-9b3a5c75804d   hosted-forwarder   true          auto-assign
5e498cd3-542c-e54f-0c58-ed43e28b568a                      true          auto-assign
da503cf1-a347-44f2-875c-4960ddb04091   hosted-forwarder   true          auto-assign

  4. 次のコマンドを実行して、ホステッドクラスターにアクセスするための kubeconfig ファイルを生成します。 

    hcp create kubeconfig --namespace <clusters_namespace> --name <hosted_cluster_namespace> > <hosted_cluster_name>.kubeconfig

  5. エージェントが added-to-existing-cluster 状態に達したら、次のコマンドを入力して、OpenShift Container Platform ノードが表示されることを確認します。 

    oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes

    以下の出力を参照してください。 

    NAME                             STATUS   ROLES    AGE      VERSION
worker-zvm-0.hostedn.example.com Ready    worker   5m41s    v1.24.0+3882f8f
worker-zvm-1.hostedn.example.com Ready    worker   6m3s     v1.24.0+3882f8f

  6. 次のコマンドを入力して、NodePool オブジェクトをスケールアップしたときに 2 台のマシンが作成されたことを確認します。 

    oc -n <hosted_control_plane_namespace> get machine.cluster.x-k8s.io

    以下の出力を参照してください。 

    NAME                                CLUSTER  NODENAME PROVIDERID     PHASE     AGE   VERSION
hosted-forwarder-79558597ff-5tbqp   hosted-forwarder-crqq5   worker-zvm-0.hostedn.example.com   agent://50c23cda-cedc-9bbd-bcf1-9b3a5c75804d   Running   41h   4.15.0
hosted-forwarder-79558597ff-lfjfk   hosted-forwarder-crqq5   worker-zvm-1.hostedn.example.com   agent://5e498cd3-542c-e54f-0c58-ed43e28b568a   Running   41h   4.15.0

  7. 次のコマンドを実行して、クラスターのバージョンとクラスター Operator のステータスを確認します。 

    oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusterversion

    以下の出力を参照してください。 

    NAME                                         VERSION       AVAILABLE   PROGRESSING   SINCE   STATUS
clusterversion.config.openshift.io/version   4.15.0   True        False         40h     Cluster version is 4.15.0

  8. 以下のコマンドを実行して、クラスター Operator のステータスを確認します。 

    oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusteroperators

クラスターの各コンポーネントの出力には、NAME、VERSION、AVAILABLE、PROGRESSING、DEGRADED、SINCE、および MESSAGE のクラスター Operator のステータスが表示されます。

出力例は、OpenShift Container Platform ドキュメントの 初期 Operator 設定 セクションを参照してください。

1.7.9.7.1. 関連情報

1.7.10. IBM Z コンピュートノード用の x86 ベアメタル上でのホスティングクラスターの設定 (テクノロジープレビュー)

テクノロジープレビュー: IBM Z (s390x) コンピュートノード用の x86 ベアメタル上でのホスティングクラスターの設定は、テクノロジープレビュー状態であり、サポートに制限があります。

ホスティングクラスターとして機能するようにクラスターを設定することで、Hosted Control Plane をデプロイメントできます。ホスティングクラスターは、コントロールプレーンがホストされる OpenShift Container Platform クラスターです。ホスティングクラスターは 管理 クラスターとも呼ばれます。

注:management クラスターは マネージド クラスターではありません。マネージドクラスターは、ハブクラスターが管理するクラスターです。

hypershift アドオンを使用してマネージドクラスターをホスティングクラスターに変換し、そのクラスターに HyperShift Operator をデプロイできます。その後、ホステッドクラスターの作成を開始できます。

マルチクラスターエンジン Operator 2.5 は、管理対象のハブクラスターであるデフォルトの local-cluster と、ホスティングクラスターとしてのハブクラスターのみをサポートします。

重要:

  • エージェントプラットフォームを使用して、Hosted Control Plane をベアメタルでプロビジョニングできます。Agent プラットフォームは、Central Infrastructure Management サービスを使用して、ホステッドクラスターにワーカーノードを追加します。Central Infrastructure Management サービスの概要は、Kube API - Getting Started Guide を参照してください。
  • 各 IBM Z システムホストは、Central Infrastructure Management によって提供される PXE イメージを使用して起動する必要があります。各ホストが起動すると、エージェントプロセスが実行されてホストの詳細が検出され、インストールが完了します。Agent カスタムリソースは、各ホストを表します。
  • Agent プラットフォームでホステッドクラスターを作成すると、HyperShift Operator は Hosted Control Plane namespace に Agent Cluster API プロバイダーをインストールします。
  • ノードプールをスケールアップすると、マシンが作成されます。Cluster API プロバイダーは、承認され、検証に合格し、現在使用されておらず、ノードプールの仕様で指定されている要件を満たすエージェントを見つけます。エージェントのステータスと状態を確認することで、エージェントのインストールを監視できます。
  • ノードプールをスケールダウンすると、エージェントは対応するクラスターからバインド解除されます。クラスターを再利用する前に、PXE イメージを使用してクラスターを起動し、ノード数を更新する必要があります。

1.7.10.1. 前提条件

  • OpenShift Container Platform クラスターに Kubernetes Operator バージョン 2.5 以降のマルチクラスターエンジンをインストールする。マルチクラスターエンジン Operator は、Red Hat Advanced Cluster Management をインストールすると自動的にインストールされます。OpenShift Container Platform OperatorHub から Operator として Red Hat Advanced Cluster Management を使用せずに、マルチクラスターエンジン Operator をインストールすることもできます。

  • マルチクラスターエンジン Operator には、少なくとも 1 つのマネージド OpenShift Container Platform クラスターが必要です。local-cluster は、マルチクラスターエンジン Operator 2.5 以降で自動的にインポートされます。local-cluster の詳細については、詳細設定 を参照してください。次のコマンドを実行して、ハブクラスターの状態を確認できます。 

    oc get managedclusters local-cluster
  • HyperShift Operator を実行するために 3 つ以上のワーカーノードを含むホスティングクラスターがある。
  • Central Infrastructure Management サービスが有効である。詳細は、Central Infrastructure Management サービスの有効化 を参照してください。
  • Hosted Control Plane コマンドラインインターフェイスをインストールする。Hosted Control Plane コマンドラインインターフェイスのインストール を参照してください。

1.7.10.2. IBM Z インフラストラクチャーの要件

エージェントプラットフォームはインフラストラクチャーを作成しませんが、インフラストラクチャーとして次のものが必要です。

  • Agents: Agent は Discovery イメージまたは PXE イメージで起動され、OpenShift Container Platform ノードとしてプロビジョニングする準備ができているホストを表します。
  • DNS: API および Ingress エンドポイントは、ルーティング可能である必要があります。

Hosted Control Plane 機能がデフォルトで有効になりました。機能を無効にした後、手動で有効にする場合、または機能を無効にする必要がある場合は、Hosted Control Plane 機能の有効化または無効化 を参照してください。

1.7.10.3. IBM Z 設定ドキュメント

前提条件を満たしたら、次のトピックを参照して、ベアメタル上に Hosted Control Plane を設定します。

  1. IBM Z を使用した Hosted Control Plane の DNS の設定
  2. ベアメタルでのホステッドクラスターの作成
  3. IBM Z コンピューティングノード用の 64 ビット x86 ベアメタル上への Hosted Control Plane 用の InfraEnv リソース作成
  4. IBM Z エージェントを InfraEnv リソースに追加する (テクノロジープレビュー)
  5. IBM Z 上のホステッドクラスターの NodePool オブジェクトのスケーリング

1.7.10.4. IBM Z エージェントを InfraEnv リソースに追加する (テクノロジープレビュー)

IBM Z 環境にエージェントを追加するには、追加の手順が必要です。これについては、このセクションで詳しく説明します。

注: 特に明記されていない限り、これらの手順は、IBM Z および IBM LinuxONE 上の z/VM と RHEL KVM の両方のインストールに適用されます。

1.7.10.4.1. KVM を使用した IBM Z のエージェントの追加

KVM を使用する IBM Z の場合は、次のコマンドを実行して、InfraEnv リソースからダウンロードした PXE イメージを使用して IBM Z 環境を開始します。エージェントが作成されると、ホストは Assisted Service と通信し、管理クラスター上の InfraEnv リソースと同じ namespace に登録します。 

virt-install \
   --name "<vm_name>" \
   --autostart \
   --ram=16384 \
   --cpu host \
   --vcpus=4 \
   --location "<path_to_kernel_initrd_image>,kernel=kernel.img,initrd=initrd.img" \
   --disk <qcow_image_path> \
   --network network:macvtap-net,mac=<mac_address> \
   --graphics none \
   --noautoconsole \
   --wait=-1 \
   --extra-args "rd.neednet=1 nameserver=<nameserver>   coreos.live.rootfs_url=http://<http_server>/rootfs.img random.trust_cpu=on rd.luks.options=discard ignition.firstboot ignition.platform.id=metal console=tty1 console=ttyS1,115200n8 coreos.inst.persistent-kargs=console=tty1 console=ttyS1,115200n8"

ISO ブートの場合は、InfraEnv リソースから ISO をダウンロードし、次のコマンドを実行してノードを起動します。 

virt-install \
  --name "<vm_name>" \
  --autostart \
  --memory=16384 \
  --cpu host \
  --vcpus=4 \
  --network network:macvtap-net,mac=<mac_address> \
  --cdrom "<path_to_image.iso>" \
  --disk <qcow_image_path> \
  --graphics none \
  --noautoconsole \
  --os-variant <os_version> \
  --wait=-1 \
1.7.10.4.2. z/VM を使用した IBM のエージェントの追加

注記: z/VM ゲストに静的 IP を使用する場合は、IP パラメーターが 2 回目の起動でも持続するように、z/VM エージェントの NMStateConfig 属性を設定する必要があります。

InfraEnv リソースからダウンロードした PXE イメージを使用して IBM Z 環境を開始するには、以下の手順を実行します。エージェントが作成されると、ホストは Assisted Service と通信し、管理クラスター上の InfraEnv リソースと同じ namespace に登録します。

  1. パラメーターファイルを更新して、rootfs_url、network_adaptor、および disk_type の値を追加します。

    以下のパラメーターファイルの例を参照してください。 

    rd.neednet=1 \
console=ttysclp0  \
coreos.live.rootfs_url=<rootfs_url> \
ip=<IP_guest_vm>::<nameserver>:255.255.255.0::<network_adaptor>:none \
nameserver=<nameserver> \
zfcp.allow_lun_scan=0 \ 1
rd.znet=qeth,<network_adaptor_range>,layer2=1 \
rd.<disk_type>=<storage> random.trust_cpu=on \ 2
rd.luks.options=discard \
ignition.firstboot ignition.platform.id=metal \
console=tty1 console=ttyS1,115200n8 \
coreos.inst.persistent-kargs="console=tty1 console=ttyS1,115200n8
    1
    VSwitch を使用したインストールの場合は、zfcp.allow_lun_scan=0 を追加します。OSA、Hipersockets、および RoCE を使用したインストールの場合は、このエントリーを省略します。
    2
    DASD タイプのディスクにインストールする場合は、rd.dasd= を使用してインストールディスクを指定します。FCP タイプのディスクにインストールする場合は、rd.zfcp= を使用します。

  2. 次のコマンドを実行して、initrd、カーネルイメージ、およびパラメーターファイルをゲスト VM に移動します。 

    vmur pun -r -u -N kernel.img $INSTALLERKERNELLOCATION/<image name>
    vmur pun -r -u -N generic.parm $PARMFILELOCATION/paramfilename
    vmur pun -r -u -N initrd.img $INSTALLERINITRAMFSLOCATION/<image name>

  3. ゲスト VM コンソールから次のコマンドを実行します。 

    cp ipl c

  4. エージェントとそのプロパティーをリスト表示するには、次のコマンドを入力します。 

    oc -n <hosted_control_plane_namespace> get agents

    以下の出力例を参照してください。 

    NAME    CLUSTER APPROVED    ROLE    STAGE
50c23cda-cedc-9bbd-bcf1-9b3a5c75804d    auto-assign
5e498cd3-542c-e54f-0c58-ed43e28b568a    auto-assign

  5. 次のコマンドを実行してエージェントを承認します。オプション: 仕様でエージェント ID <installation_disk_id> と <hostname> を設定できます。 

    oc -n <hosted_control_plane_namespace> patch agent 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d -p '{"spec":{"installation_disk_id":"/dev/sda","approved":true,"hostname":"worker-zvm-0.hostedn.example.com"}}' --type merge

  6. 次のコマンドを実行して、エージェントが承認されていることを確認します。 

    oc -n <hosted_control_plane_namespace> get agents

    以下の出力例を参照してください。 

    NAME                                            CLUSTER     APPROVED   ROLE          STAGE
50c23cda-cedc-9bbd-bcf1-9b3a5c75804d             true       auto-assign
5e498cd3-542c-e54f-0c58-ed43e28b568a             true       auto-assign

1.7.10.5. IBM Z を使用した Hosted Control Plane の DNS の設定

ホステッドクラスターの API サーバーは、'NodePort' サービスとして公開されます。API サーバーに到達可能な宛先を指す api.<hosted-cluster-name>.<base-domain> の DNS エントリーが存在する必要があります。

DNS エントリーは、Hosted Control Plane を実行しているマネージドクラスター内のノードの 1 つを指すレコードと同様、単純化できます。

エントリーは、受信トラフィックを Ingress Pod にリダイレクトするためにデプロイされるロードバランサーを指すこともできます。

次の DNS 設定例を参照してください。 

$ cat /var/named/<example.krnl.es.zone>

以下の出力例を参照してください。 

$ TTL 900
@ IN  SOA bastion.example.krnl.es.com. hostmaster.example.krnl.es.com. (
      2019062002
      1D 1H 1W 3H )
  IN NS bastion.example.krnl.es.com.
;
;
api                   IN A 1xx.2x.2xx.1xx 1
api-int               IN A 1xx.2x.2xx.1xx
;
;
*.apps        IN A 1xx.2x.2xx.1xx
;
;EOF
1
このレコードは、Hosted Control Plane の受信トラフィックと送信トラフィックを処理する API ロードバランサーの IP アドレスを参照します。

IBM z/VM の場合、エージェントの IP アドレスに対応する IP アドレスを追加します。 

compute-0              IN A 1xx.2x.2xx.1yy
compute-1              IN A 1xx.2x.2xx.1yy

1.7.10.6. IBM Z コンピューティングノードの x86 ベアメタル上への Hosted Control Plane 用の InfraEnv リソース作成

InfraEnv は、PXE イメージを使用して起動されるホストがエージェントとして参加できる環境です。この場合、エージェントは Hosted Control Plane と同じ namespace に作成されます。

InfraEnv リソースを作成するには、次の手順を参照してください。

  1. 設定を含む YAML ファイルを作成します。以下の例を参照してください。 

    apiVersion: agent-install.openshift.io/v1beta1
kind: InfraEnv
metadata:
  name: <hosted-cluster-name>
  namespace: <hosted-control-plane-namespace>
spec:
  cpuArchitecture: s390x
  pullSecretRef:
    name: pull-secret
  sshAuthorizedKey: <ssh-public-key>
  2. ファイルを infraenv-config.yaml として保存します。

  3. 次のコマンドを入力して設定を適用します。 

    oc apply -f infraenv-config.yaml

  4. initrd.img、kernel.img、または rootfs.img などの PXE イメージをダウンロードする URL を取得するには、次のコマンドを入力します。このイメージは、IBM Z マシンがエージェントとして参加できるようにします。 

    oc -n <hosted-control-plane-namespace> get InfraEnv <hosted-cluster-name> -o json

1.7.10.7. IBM Z 上のホステッドクラスターの NodePool オブジェクトのスケーリング

NodePool オブジェクトは、ホステッドクラスターの作成時に作成されます。NodePool オブジェクトをスケーリングすることで、Hosted Control Plane にさらに多くのコンピュートノードを追加できます。

  1. 次のコマンドを実行して、NodePool オブジェクトを 2 つのノードにスケーリングします。 

    oc -n <clusters_namespace> scale nodepool <nodepool_name> --replicas 2

    Cluster API エージェントプロバイダーは、ホステッドクラスターに割り当てられる 2 つのエージェントをランダムに選択します。これらのエージェントはさまざまな状態を経て、最終的に OpenShift Container Platform ノードとしてホステッドクラスターに参加します。エージェントは次の順序で移行フェーズを通過します。

    • binding
    • discovering
    • insufficient
    • installing
    • installing-in-progress
    • added-to-existing-cluster

  2. 次のコマンドを実行して、スケールされた特定のエージェントのステータスを確認します。 

    oc -n <hosted_control_plane_namespace> get agent -o jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}'

    以下の出力を参照してください。 

    BMH: Agent: 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d State: known-unbound
BMH: Agent: 5e498cd3-542c-e54f-0c58-ed43e28b568a State: insufficient

  3. 次のコマンドを実行して、移行フェーズを表示します。 

    oc -n <hosted_control_plane_namespace> get agent

    以下の出力を参照してください。 

    NAME                                   CLUSTER           APPROVED       ROLE        STAGE
50c23cda-cedc-9bbd-bcf1-9b3a5c75804d   hosted-forwarder   true          auto-assign
5e498cd3-542c-e54f-0c58-ed43e28b568a                      true          auto-assign
da503cf1-a347-44f2-875c-4960ddb04091   hosted-forwarder   true          auto-assign

  4. 次のコマンドを実行して、ホステッドクラスターにアクセスするための kubeconfig ファイルを生成します。 

    hcp create kubeconfig --namespace <clusters_namespace> --name <hosted_cluster_namespace> > <hosted_cluster_name>.kubeconfig

  5. エージェントが added-to-existing-cluster 状態に達したら、次のコマンドを入力して、OpenShift Container Platform ノードが表示されることを確認します。 

    oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes

    以下の出力を参照してください。 

    NAME                             STATUS   ROLES    AGE      VERSION
worker-zvm-0.hostedn.example.com Ready    worker   5m41s    v1.24.0+3882f8f
worker-zvm-1.hostedn.example.com Ready    worker   6m3s     v1.24.0+3882f8f

    Cluster Operator は、ワークロードをノードに追加することによって調整を開始します。

  6. 次のコマンドを入力して、NodePool オブジェクトをスケールアップしたときに 2 台のマシンが作成されたことを確認します。 

    oc -n <hosted_control_plane_namespace> get machine.cluster.x-k8s.io

    以下の出力を参照してください。 

    NAME                                CLUSTER  NODENAME PROVIDERID     PHASE     AGE   VERSION
hosted-forwarder-79558597ff-5tbqp   hosted-forwarder-crqq5   worker-zvm-0.hostedn.example.com   agent://50c23cda-cedc-9bbd-bcf1-9b3a5c75804d   Running   41h   4.15.0
hosted-forwarder-79558597ff-lfjfk   hosted-forwarder-crqq5   worker-zvm-1.hostedn.example.com   agent://5e498cd3-542c-e54f-0c58-ed43e28b568a   Running   41h   4.15.0

  7. 次のコマンドを実行して、クラスターのバージョンを確認します。 

    oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusterversion,co

    以下の出力を参照してください。 

    NAME                                         VERSION       AVAILABLE   PROGRESSING   SINCE   STATUS
clusterversion.config.openshift.io/version   4.15.0-ec.2   True        False         40h     Cluster version is 4.15.0-ec.2

  8. 以下のコマンドを実行して、クラスター Operator のステータスを確認します。 

    oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusteroperators

クラスターの各コンポーネントの出力には、NAME、VERSION、AVAILABLE、PROGRESSING、DEGRADED、SINCE、および MESSAGE のクラスター Operator のステータスが表示されます。

出力例は、OpenShift Container Platform ドキュメントの 初期 Operator 設定 セクションを参照してください。

1.7.10.7.1. 関連情報

1.7.11. OpenShift Virtualization での Hosted Control Plane クラスターの管理

Hosted Control Plane と Red Hat 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 のホストされるクラスターを作成できます。ホステッドクラスターは、マネージドクラスターとして自動的にインポートされます。この自動インポート機能を無効にする場合は、マルチクラスターエンジン Operator へのホストクラスターの自動インポートの無効化 を参照してください。

重要:

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

1.7.11.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 ホスティングクラスターは、デフォルトの 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 リポジトリーの有効なプルシークレットファイルが必要です。詳細は、ユーザーがプロビジョニングしたインフラストラクチャーを使用して x86_64 プラットフォームに OpenShift をインストールする を参照してください。
  • Hosted Control Plane コマンドラインインターフェイスをインストールする 必要があります。
  • クラスターをプロビジョニングする前に、ロードバランサーを設定する必要があります。詳細は、オプション: MetalLB の設定 を参照してください。
  • ネットワークパフォーマンスを最適化するには、KubeVirt 仮想マシンをホストする OpenShift Container Platform クラスターで 9000 以上のネットワーク最大伝送単位 (MTU) を使用します。低い MTU 設定を使用すると、ネットワーク遅延とホストされる Pod のスループットに影響があります。MTU が 9000 以上の場合にのみ、ノードプールでマルチキューを有効にします。

  • マルチクラスターエンジン Operator には、少なくとも 1 つのマネージド OpenShift Container Platform クラスターが必要です。local-cluster は自動的にインポートされます。local-cluster の詳細については、詳細設定 を参照してください。次のコマンドを実行して、ハブクラスターの状態を確認できます。 

    oc get managedclusters local-cluster

1.7.11.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 アドレスによるアクセスを簡素化します。

Red Hat OpenShift Virtualization 上の Hosted Control Plane に関する関連資料は、次のドキュメントを参照してください。

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

OpenShift Container Platform 4.14 以降では、KubeVirt を使用してクラスターを作成でき、外部インフラストラクチャーを使用して作成することも可能です。KubeVirt を使用した作成プロセスの詳細は、以下をご覧ください。

1.7.11.3.1. ホストされたクラスターの作成

  1. ホストされたクラスターを作成するには、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
    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. ホステッドクラスターへのアクセス の説明に従って、ホステッドクラスターにアクセスします。
1.7.11.3.2. 外部インフラストラクチャーを使用したホステッドクラスターの作成

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

  • 管理クラスター は HyperShift Operator を実行し、ホステッドクラスターのコントロールプレーン Pod をホストする OpenShift Container Platform クラスターです。
  • インフラストラクチャークラスター は、ホステッドクラスターの KubeVirt ワーカー VM を実行する OpenShift Container Platform クラスターです。
  • デフォルトでは、管理クラスターは VM をホストするインフラストラクチャークラスターとしても機能します。ただし、外部インフラストラクチャーの場合、管理クラスターとインフラストラクチャークラスターは異なります。
1.7.11.3.2.1. 外部インフラストラクチャーの前提条件
  • KubeVirt ノードをホストする外部インフラストラクチャークラスター上に namespace が必要です。
  • 外部インフラストラクチャークラスター用の kubeconfig ファイルが必要です。
1.7.11.3.2.2. hcp コマンドラインインターフェイスを使用したホステッドクラスターの作成

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

  1. 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 は別のインフラストラクチャークラスターでホストされます。

  2. ホステッドクラスターへのアクセス の説明に従って、ホステッドクラスターにアクセスします。
1.7.11.3.3. コンソールを使用したホステッドクラスターの作成

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

  1. OpenShift Container Platform Web コンソールを開き、管理者の認証情報を入力してログインします。コンソールを開く手順については、OpenShift Container Platform ドキュメントの Web コンソールへのアクセス を参照してください。
  2. コンソールヘッダーで、All Clusters が選択されていることを確認します。
  3. Infrastructure > Clusters をクリックします。
  4. Create cluster > Red Hat OpenShift Virtualization > Hosted をクリックします。

  5. Create cluster ページで、プロンプトに従ってクラスターとノードプールの詳細を入力します。

    注記:

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

  6. エントリーを確認し、Create をクリックします。

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

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

1.7.11.4. デフォルトの 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 の動作にのみ適用されます。

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

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

1.7.11.4.1.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
ホステッドクラスターの名前を指定します (例: example)。
2
ワーカー数を指定します (例: 2)。
3
プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
4
メモリーの値を指定します (例: 6Gi)。
5
CPU の値を指定します (例: 2)。
6
ベースドメインを指定します (例: hypershift.lab)。

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

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

    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

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

    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 バージョンに置き換えます。

    次の手順では、出力内のエラーを修正します。

    注記: ホストされたクラスターがベアメタル上にある場合は、ロードバランサーサービスを設定するために MetalLB が必要になる場合があります。詳細は、オプション: MetalLB の設定 を参照してください。

1.7.11.4.1.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 ノードポート値を指定します。
1.7.11.4.1.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 バージョンに置き換えます。

1.7.11.4.1.4. 関連情報

1.7.11.5. オプション: MetalLB の設定

MetalLB を設定する前に、MetalLB Operator をインストールする必要があります。詳細は、OpenShift Container Platform ドキュメントの 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
1.7.11.5.1. 関連情報

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

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

1.7.11.6.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 と名前に置き換えます。
1.7.11.6.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 リソースが仮想マシンに割り当てられることを保証します。
1.7.11.6.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> をそれぞれラベルのキーと値に置き換えます。

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

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

    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
1.7.11.7.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 バージョンに置き換えます。

1.7.11.7.1.1. 関連情報

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

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

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

    oc get --namespace clusters hostedclusters ${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 $CLUSTER_NAME > $CLUSTER_NAME-kubeconfig
    oc get co --kubeconfig=$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

1.7.11.9. OpenShift Virtualization での Hosted Control Plane のストレージの設定

高度な設定が提供されていない場合、デフォルトのストレージクラスが KubeVirt 仮想マシン (VM) イメージ、KubeVirt CSI マッピング、および etcd ボリュームに使用されます。

1.7.11.9.1. KubeVirt CSI ストレージクラスのマッピング

KubeVirt CSI では、ReadWriteMany アクセスモードを持つインフラストラクチャーストレージクラスをホステッドクラスターに公開することができます。--infra-storage-class-mapping 引数を使用して、クラスターの作成時にインフラストラクチャークラスターストレージクラスとホストクラスターストレージクラスのマッピングを設定できます。

インフラストラクチャーストレージクラスをホステッドストレージクラスにマップするには、次の例を参照してください。 

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-storage-class-mapping=<storage-class>/<hosted-storage-class> \ 6
1
ホストされているクラスターの名前を指定します (例: example)。
2
ワーカー数を指定します (例: 2)。
3
プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
4
メモリーの値を指定します (例: 6Gi)。
5
CPU の値を指定します (例: 2)。
6
<storage-class> をインフラストラクチャーストレージクラス名に置き換え、<hosted-storage-class> をホストされたクラスターストレージクラス名に置き換えます。create コマンド内で --infra-storage-class-mapping 引数を複数回使用できます。

ホスト型クラスターを作成すると、インフラストラクチャーストレージクラスがホストされたクラスター内に表示されます。これらのストレージクラスのいずれかを使用するホステッドクラスター内に PVC を作成すると、KubeVirt CSI はクラスターの作成時に設定したインフラストラクチャーストレージクラスマッピングを使用してそのボリュームをプロビジョニングします。

注記: KubeVirt CSI は、ReadWriteMany (RWX) アクセスが可能なインフラストラクチャーストレージクラスのマッピングのみをサポートします。

1.7.11.9.2. KubeVirt VM ルートボリュームの設定

クラスターの作成時に、--root-volume-storage-class 引数を使用して、KubeVirt 仮想マシンルートボリュームをホストするために使用されるストレージクラスを設定できます。

KubeVirt VM のカスタムストレージクラスとボリュームサイズを設定するには、次の例を参照してください。 

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

結果は、ocs-storagecluster-ceph-rdb ストレージクラスにホストされる PVC 上でホストされる仮想マシンを含むホストされたクラスターになります。

1.7.11.9.3. KubeVirt VM イメージキャッシュの有効化

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

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

  1. VM イメージは、ホステッドクラスターに関連付けられた PVC にインポートされます。
  2. その PVC の一意のクローンは、クラスターにワーカーノードとして追加されるすべての KubeVirt VM に対して作成されます。

イメージキャッシュを使用すると、イメージのインポートが 1 つだけ必要になるため、VM の起動時間が短縮されます。ストレージクラスがコピーオンライトクローン作成をサポートしている場合、クラスター全体のストレージ使用量をさらに削減できます。

イメージキャッシュを有効にするには、クラスターの作成時に、次の例に示すように、--root-volume-cache-strategy=PVC 引数を使用します。 

hcp create cluster kubevirt \
--name <hosted-cluster-name> \ 1
--node-pool-replicas <worker-count> \ 2
--pull-secret <path-to-pull-secret> \ 3
--memory <value-for-memory> \ 4
--cores <value-for-cpu> \ 5
--root-volume-cache-strategy=PVC 6
1
ホストされているクラスターの名前を指定します (例: example)。
2
ワーカー数を指定します (例: 2)。
3
プルシークレットへのパスを指定します (例: /user/name/pullsecret)。
4
メモリーの値を指定します (例: 6Gi)。
5
CPU の値を指定します (例: 2)。
6
イメージキャッシュのストラテジー (例: PVC) を指定します。
1.7.11.9.4. etcd ストレージの設定

クラスターの作成時に、--etcd-storage-class 引数を使用して、etcd データをホストするために使用されるストレージクラスを設定できます。

etcd のストレージクラスを設定するには、次の例を参照してください。 

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

1.7.11.10. OpenShift Virtualization 上のホステッドクラスターの破棄

ホステッドクラスターとそのマネージドクラスターリソースを破棄するには、次の手順を実行します。

  1. 次のコマンドを実行して、マルチクラスターエンジン Operator のマネージドクラスターリソースを削除します。 

    oc delete managedcluster <managed_cluster_name>

    ここで、<managed_cluster_name> は管理対象クラスターの名前です。

  2. 次のコマンドを実行して、ホステッドクラスターとそのバックエンドリソースを削除します。 

    hcp destroy cluster kubevirt --name <hosted_cluster_name>

    <hosted_cluster_name> をホストされたクラスター名に置き換えます。

1.7.12. 非接続環境での Hosted Control Plane の設定

非接続環境は、インターネットに接続されておらず、Hosted Control Plane をベースとして使用する OpenShift Container Platform クラスターです。

テクノロジープレビュー: IPv4 または IPv6 ネットワークを使用して、ベアメタルプラットフォーム上の非接続環境に Hosted Control Plane をデプロイメントできます。さらに、非接続環境の Hosted Control Plane は、テクノロジープレビュー機能としてデュアルスタックネットワークで使用できます。Red Hat OpenShift Virtualization プラットフォームを使用する場合は、オフライン環境の Hosted Control Plane がテクノロジープレビュー機能として利用できます。

1.7.12.1. 非接続環境のアーキテクチャー

Agent プラットフォームを使用して、ベアメタル上に Hosted Control Plane をプロビジョニングできます。Agent プラットフォームは、Central Infrastructure Management サービスを使用して、ホステッドクラスターにワーカーノードを追加します。Central Infrastructure Management の概要は、central infrastructure management の有効化 を参照してください。

非接続環境の次のアーキテクチャー図を参照してください。

Disconnected architecture diagram

  1. TLS サポートを備えたレジストリー証明書のデプロイメント、Web サーバー、DNS などのインフラストラクチャーサービスを設定して、切断されたデプロイメントが確実に機能するようにします。

  2. openshift-config namespace に config map を作成します。config map の内容はレジストリー CA 証明書です。config map の data フィールドには、次のキーと値が含まれている必要があります。

    • キー: <registry_dns_domain_name>..<port> (例: registry.hypershiftdomain.lab..5000:)ポートを指定するときは、レジストリー DNS ドメイン名の後に .. を配置するようにしてください。
    • 値: 証明書の内容

    config map の作成に関する詳細は、IPv4 ネットワークの TLS 証明書の設定 を参照してください。

  3. images.config.openshift.io カスタムリソース (CR) に、name: registry-config という値を持つ additionalTrustedCA フィールドを追加します。

  4. multicluster-engine namespace に config map を作成します。次のサンプル設定を参照してください。 

    apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-registries
  namespace: multicluster-engine
  labels:
    app: assisted-service
data:
  ca-bundle.crt: | 1
    -----BEGIN CERTIFICATE-----
    ...
    ...
    ...
    -----END CERTIFICATE-----
  registries.conf: | 2
    unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]

    [[registry]]
    prefix = ""
    location = "registry.redhat.io/openshift4"
    mirror-by-digest-only = true

    [[registry.mirror]]
      location = "registry.ocp-edge-cluster-0.qe.lab.redhat.com:5000/openshift4"

    [[registry]]
    prefix = ""
    location = "registry.redhat.io/rhacm2"
    mirror-by-digest-only = true
...
...
1
レジストリーの CA 証明書が含まれます。
2
registries.conf ファイルの内容が RAW 形式で含まれています。
  1. マルチクラスターエンジン Operator namespace では、multiclusterengine CR を作成します。これにより、Agent アドオンと hypershift-addon アドオンの両方が有効になります。切断されたデプロイメントでの動作を変更するには、マルチクラスターエンジン Operator namespace に config map が含まれている必要があります。namespace には、multicluster-engine、assisted-service、および hypershift-addon-manager Pod も含まれます。

  2. ホストされたクラスターをデプロイするには、次のコンポーネントのオブジェクトを作成します。

    • シークレット: シークレットには、プルシークレット、SSH キー、etcd 暗号化キーが含まれます。
    • config map: config map には、プライベートレジストリーの CA 証明書が含まれています。
    • HostedCluster: HostedCluster リソースは、ホストされたクラスターの設定を定義します。
    • NodePool: NodePool リソースは、データプレーンに使用するマシンを参照するノードプールを識別します。
  3. ホストされたクラスターオブジェクトを作成すると、HyperShift Operator は HostedControlPlane namespace にコントロールプレーン Pod を作成します。HostedControlPlane namespace は、Agent、ベアメタルホスト、InfraEnv リソースなどのコンポーネントもホストします。
  4. InfraEnv リソースを作成します。ISO イメージを生成した後、ベースボード管理コントローラー (BMC) の認証情報を含むベアメタルホストとそのシークレットを作成します。
  5. openshift-machine-api namespace の Metal3 Operator は、新しいベアメタルホストを検査します。
  6. Metal3 Operator は、LiveISO 値および RootFS 値を使用して BMC に接続し、起動しようとします。マルチクラスターエンジン Operator の namespace の AgentServiceConfig CR を通じて、LiveISO 値と RootFS 値を指定できます。
  7. HostedCluster リソースのワーカーノードが起動された後、エージェントコンテナーが起動されます。
  8. NodePool リソースを、HostedCluster リソースのワーカーノードの数に合わせてスケーリングします。
  9. デプロイメントプロセスが完了するまで待ちます。

1.7.12.2. 前提条件

オフライン環境で Hosted Control Plane を設定するには、次の前提条件を満たす必要があります。

  • CPU: 提供される CPU の数によって、同時に実行できるホストクラスターの数が決まります。通常、3 つのノードの場合、各ノードに 16 個の CPU を使用します。最小限の開発では、3 つのノードの場合、各ノードに 12 個の CPU を使用できます。
  • メモリー: RAM の量は、ホストできるホストクラスターの数に影響します。各ノードに 48 GB の RAM を使用します。最小限の開発であれば、18 GB の RAM で十分です。

  • ストレージ: マルチクラスターエンジン Operator には SSD ストレージを使用します。

    • 管理クラスター: 250 GB。
    • レジストリー: 必要なレジストリーストレージは、ホストされるリリース、Operator、およびイメージの数によって異なります。500 GB が必要になる場合があります。ホストされたクラスターをホストするディスクとは別にすることを推奨します。
    • Web サーバー: 必要な Web サーバーストレージは、ホストされる ISO とイメージの数によって異なります。500 GB 必要になる場合があります。

  • 実稼働環境: 実稼働環境の場合、管理クラスター、レジストリー、および Web サーバーを異なるディスク上に分離します。本番環境では次の設定例を参照してください。

    • レジストリー: 2TB
    • 管理クラスター: 500 GB
    • Web サーバー:2TB

1.7.12.3. OpenShift Container Platform リリースイメージダイジェストの抽出

タグ付けされたイメージを使用して、OpenShift Container Platform リリースイメージダイジェストを抽出できます。以下の手順を実行します。

  1. 次のコマンドを実行して、イメージダイジェストを取得します。 

    oc adm release info <tagged_openshift_release_image> | grep "Pull From"

    <tagged_openshift_release_image> を、サポートされている OpenShift Container Platform バージョンのタグ付きイメージに置き換えます (例: quay.io/openshift-release-dev/ocp-release:4.14.0-x8_64)。

    以下の出力例を参照してください。 

    Pull From: quay.io/openshift-release-dev/ocp-release@sha256:69d1292f64a2b67227c5592c1a7d499c7d00376e498634ff8e1946bc9ccdddfe

    イメージタグとダイジェストの詳細は、OpenShift Container Platform ドキュメントの イメージストリームでのイメージの参照 を参照してください。

1.7.12.3.1. 関連情報

1.7.12.4. オフライン環境でのユーザーワークロードの監視

hypershift-addon マネージドクラスターアドオンは、HyperShift Operator の --enable-uwm-telemetry-remote-write オプションを有効にします。このオプションを有効にすると、ユーザーワークロードの監視が有効になり、コントロールプレーンから Telemetry メトリックをリモートで書き込むことができるようになります。

インターネットに接続されていない OpenShift Container Platform クラスターにマルチクラスターエンジン Operator をインストールした場合、次のコマンドを入力して HyperShift Operator のユーザーワークロードモニタリング機能を実行しようとすると、この機能はエラーで失敗します。 

oc get events -n hypershift

エラーの例を以下に示します。 

LAST SEEN   TYPE      REASON           OBJECT                MESSAGE
4m46s       Warning   ReconcileError   deployment/operator   Failed to ensure UWM telemetry remote write: cannot get telemeter client secret: Secret "telemeter-client" not found

このエラーを回避するには、local-cluster namespace に config map を作成して、ユーザーワークロード監視オプションを無効にする必要があります。アドオンを有効にする前または後に config map を作成できます。アドオンエージェントは、HyperShift Operator を再設定します。

次の config map を作成します。 

kind: ConfigMap
apiVersion: v1
metadata:
  name: hypershift-operator-install-flags
  namespace: local-cluster
data:
  installFlagsToAdd: ""
  installFlagsToRemove: "--enable-uwm-telemetry-remote-write"
1.7.12.4.1. Hosted Control Plane 機能のステータス確認

Hosted Control Plane 機能がデフォルトで有効になりました。

  1. この機能が無効になっており、有効にする場合は、次のコマンドを入力します。multiclusterengine は、マルチクラスターエンジン Operator インスタンスの名前に置き換えます。 

    oc patch mce <multiclusterengine> --type=merge -p '{"spec":{"overrides":{"components":[{"name":"hypershift","enabled": true}]}}}'

    この機能を有効にすると、hypershift-addon マネージドクラスターアドオンが local-cluster マネージドクラスターにインストールされ、アドオンエージェントはマルチクラスターエンジン Operator ハブクラスターに HyperShift Operator をインストールします。

  2. 次のコマンドを入力して、hypershift-addon マネージドクラスターアドオンがインストールされていることを確認します。 

    oc get managedclusteraddons -n local-cluster hypershift-addon

  3. 結果の出力を確認します。 

    NAME               AVAILABLE   DEGRADED   PROGRESSING
hypershift-addon   True        False

  4. このプロセス時のタイムアウトを回避するには、以下のコマンドを入力します。 

    oc wait --for=condition=Degraded=True managedclusteraddons/hypershift-addon -n local-cluster --timeout=5m
    oc wait --for=condition=Available=True managedclusteraddons/hypershift-addon -n local-cluster --timeout=5m

    プロセスが完了すると、hypershift-addon マネージドクラスターアドオンと HyperShift Operator がインストールされ、local-cluster マネージドクラスターがホステッドクラスターをホストおよび管理できるようになります。

1.7.12.4.2. インフラストラクチャーノード上で実行する hypershift-addon マネージドクラスターアドオンの設定

デフォルトでは、hypershift-addon マネージドクラスターアドオンに対してノード配置設定は指定されていません。インフラストラクチャーノード上でアドオンを実行することを検討してください。そうすることで、サブスクリプション数に対する請求コストの発生や、個別のメンテナンスおよび管理タスクの発生を防ぐことができます。

  1. ハブクラスターにログインします。

  2. 次のコマンドを入力して、hypershift-addon-deploy-config アドオンデプロイメント設定仕様を開いて編集します。 

    oc edit addondeploymentconfig hypershift-addon-deploy-config -n multicluster-engine

  3. 以下の例のように、nodePlacement フィールドを仕様に追加します。 

    apiVersion: addon.open-cluster-management.io/v1alpha1
kind: AddOnDeploymentConfig
metadata:
  name: hypershift-addon-deploy-config
  namespace: multicluster-engine
spec:
  nodePlacement:
    nodeSelector:
      node-role.kubernetes.io/infra: ""
    tolerations:
    - effect: NoSchedule
      key: node-role.kubernetes.io/infra
      operator: Exists
  4. 変更を保存します。hypershift-addon マネージドクラスターアドオンは、新規および既存のマネージドクラスターのインフラストラクチャーノードにデプロイされます。

1.7.12.5. IPv4 を使用して非接続環境で Hosted Control Plane を設定する

IPv4 ネットワークを使用して、非接続環境で Hosted Control Plane を設定できます。IPv4 範囲では、IPv6 またはデュアルスタック設定よりも必要な外部コンポーネントが少なくなります。

IPv4 ネットワーク上で Hosted Control Plane を設定するには、次の手順を確認してください。

  1. IPv4 ネットワーク用のハイパーバイザーを設定する
  2. IPv4 ネットワークの DNS を設定する
  3. IPv4 ネットワーク用のレジストリーをデプロイする
  4. IPv4 ネットワークの管理クラスターを設定する
  5. IPv4 ネットワーク用の Web サーバーを設定する
  6. IPv4 ネットワークのイメージミラーリングを設定する
  7. IPv4 ネットワーク用のマルチクラスターエンジン Operator をデプロイする
  8. IPv4 ネットワークの TLS 証明書を設定する
  9. IPv4 ネットワークのホステッドクラスターをデプロイする
  10. IPv4 ネットワークのデプロイメントを終了する
1.7.12.5.1. IPv4 ネットワーク用のハイパーバイザーを設定する

以下の情報は、仮想マシン環境にのみ適用されます。

1.7.12.5.1.1. 仮想 OpenShift Container Platform クラスターのパッケージへのアクセスおよびデプロイ

  1. 仮想 OpenShift Container Platform 管理クラスターをデプロイするには、以下のコマンドを入力して必要なパッケージにアクセスします。 

    sudo dnf install dnsmasq radvd vim golang podman bind-utils net-tools httpd-tools tree htop strace tmux -y

  2. 次のコマンドを入力して、Podman サービスを有効にして起動します。 

    systemctl enable --now podman

  3. kcli を使用して OpenShift Container Platform 管理クラスターおよびその他の仮想コンポーネントをデプロイするには、以下のコマンドを入力してハイパーバイザーをインストールおよび設定します。 

    sudo yum -y install libvirt libvirt-daemon-driver-qemu qemu-kvm
    sudo usermod -aG qemu,libvirt $(id -un)
    sudo newgrp libvirt
    sudo systemctl enable --now libvirtd
    sudo dnf -y copr enable karmab/kcli
    sudo dnf -y install kcli
    sudo kcli create pool -p /var/lib/libvirt/images default
    kcli create host kvm -H 127.0.0.1 local
    sudo setfacl -m u:$(id -un):rwx /var/lib/libvirt/images
    kcli create network  -c 192.168.122.0/24 default
1.7.12.5.1.2. ネットワークマネージャーディスパッチャーの有効化

  1. ネットワークマネージャーのディスパッチャーを有効にして、仮想マシンが必要なドメイン、ルート、およびレジストリーを解決できるようにします。ネットワークマネージャーディスパッチャーを有効にするには、/etc/NetworkManager/dispatcher.d/ ディレクトリーに次の内容を含む forcedns という名前のスクリプトを作成し、環境に合わせて必要に応じて値を置き換えます。 

    #!/bin/bash

export IP="192.168.126.1" 1
export BASE_RESOLV_CONF="/run/NetworkManager/resolv.conf"

if ! [[ `grep -q "$IP" /etc/resolv.conf` ]]; then
export TMP_FILE=$(mktemp /etc/forcedns_resolv.conf.XXXXXX)
cp $BASE_RESOLV_CONF $TMP_FILE
chmod --reference=$BASE_RESOLV_CONF $TMP_FILE
sed -i -e "s/dns.base.domain.name//" -e "s/search /& dns.base.domain.name /" -e "0,/nameserver/s/nameserver/& $IP\n&/" $TMP_FILE 2
mv $TMP_FILE /etc/resolv.conf
fi
echo "ok"
    1
    OpenShift Container Platform 管理クラスターをホストするハイパーバイザーインターフェイスの IP アドレスを指すように IP 変数を変更します。
    2
    dns.base.domain.name は DNS ベースドメイン名に置き換えます。

  2. ファイルを作成したら、次のコマンドを入力してパーミッションを追加します。 

    chmod 755 /etc/NetworkManager/dispatcher.d/forcedns
  3. スクリプトを実行し、出力が ok を返すことを確認します。
1.7.12.5.1.3. BMC アクセスの設定

  1. 仮想マシンのベースボード管理コントローラー (BMC) をシミュレートするように ksushy を設定します。次のコマンドを入力します。 

    sudo dnf install python3-pyOpenSSL.noarch python3-cherrypy -y
    kcli create sushy-service --ssl --port 9000
    sudo systemctl daemon-reload
    systemctl enable --now ksushy

  2. 次のコマンドを入力して、サービスが正しく機能しているかどうかをテストします。 

    systemctl status ksushy
1.7.12.5.1.4. 接続を許可するためのハイパーバイザーシステムの設定

開発環境で作業している場合は、環境内の各種仮想ネットワークを介したさまざまなタイプの接続を許可するようにハイパーバイザーシステムを設定します。

注: 実稼働環境で作業している場合は、安全な環境を維持するために、firewalld サービスの適切なルールを確立し、SELinux ポリシーを設定する必要があります。

  • SELinux の場合は、次のコマンドを入力します。 

    sed -i s/^SELINUX=.*$/SELINUX=permissive/ /etc/selinux/config; setenforce 0

  • firewalld の場合は、次のコマンドを入力します。 

    systemctl disable --now firewalld

  • libvirtd の場合は、以下のコマンドを入力します。 

    systemctl restart libvirtd
    systemctl enable --now libvirtd

次に、環境に合わせて DNS を設定します。

1.7.12.5.1.5. 関連情報
1.7.12.5.2. IPv4 ネットワークの DNS を設定する

この手順は、仮想環境とベアメタル環境の両方で、オフライン環境とオンライン環境の両方で必須です。仮想環境とベアメタル環境の主な違いは、リソースを設定する場所にあります。ベアメタル環境では、dnsmasq のような軽量のソリューションではなく、Bind のようなソリューションを使用してください。

次にレジストリーをデプロイします。

1.7.12.5.3. IPv4 ネットワーク用のレジストリーをデプロイする

開発環境の場合は、Podman コンテナーを使用して、小規模な自己ホスト型レジストリーをデプロイします。実稼働環境では、Red Hat Quay、Nexus、Artifactory などのエンタープライズでホストされるレジストリーを使用します。

Podman を使用して小規模なレジストリーをデプロイするには、以下の手順を実行します。

  1. 特権ユーザーとして ${HOME} ディレクトリーにアクセスし、次のスクリプトを作成します。 

    #!/usr/bin/env bash

set -euo pipefail

PRIMARY_NIC=$(ls -1 /sys/class/net | grep -v podman | head -1)
export PATH=/root/bin:$PATH
export PULL_SECRET="/root/baremetal/hub/openshift_pull.json" 1

if [[ ! -f $PULL_SECRET ]];then
  echo "Pull Secret not found, exiting..."
  exit 1
fi

dnf -y install podman httpd httpd-tools jq skopeo libseccomp-devel
export IP=$(ip -o addr show $PRIMARY_NIC | head -1 | awk '{print $4}' | cut -d'/' -f1)
REGISTRY_NAME=registry.$(hostname --long)
REGISTRY_USER=dummy
REGISTRY_PASSWORD=dummy
KEY=$(echo -n $REGISTRY_USER:$REGISTRY_PASSWORD | base64)
echo "{\"auths\": {\"$REGISTRY_NAME:5000\": {\"auth\": \"$KEY\", \"email\": \"sample-email@domain.ltd\"}}}" > /root/disconnected_pull.json
mv ${PULL_SECRET} /root/openshift_pull.json.old
jq ".auths += {\"$REGISTRY_NAME:5000\": {\"auth\": \"$KEY\",\"email\": \"sample-email@domain.ltd\"}}" < /root/openshift_pull.json.old > $PULL_SECRET
mkdir -p /opt/registry/{auth,certs,data,conf}
cat <<EOF > /opt/registry/conf/config.yml
version: 0.1
log:
  fields:
    service: registry
storage:
  cache:
    blobdescriptor: inmemory
  filesystem:
    rootdirectory: /var/lib/registry
  delete:
    enabled: true
http:
  addr: :5000
  headers:
    X-Content-Type-Options: [nosniff]
health:
  storagedriver:
    enabled: true
    interval: 10s
    threshold: 3
compatibility:
  schema1:
    enabled: true
EOF
openssl req -newkey rsa:4096 -nodes -sha256 -keyout /opt/registry/certs/domain.key -x509 -days 3650 -out /opt/registry/certs/domain.crt -subj "/C=US/ST=Madrid/L=San Bernardo/O=Karmalabs/OU=Guitar/CN=$REGISTRY_NAME" -addext "subjectAltName=DNS:$REGISTRY_NAME"
cp /opt/registry/certs/domain.crt /etc/pki/ca-trust/source/anchors/
update-ca-trust extract
htpasswd -bBc /opt/registry/auth/htpasswd $REGISTRY_USER $REGISTRY_PASSWORD
podman create --name registry --net host --security-opt label=disable --replace -v /opt/registry/data:/var/lib/registry:z -v /opt/registry/auth:/auth:z -v /opt/registry/conf/config.yml:/etc/docker/registry/config.yml -e "REGISTRY_AUTH=htpasswd" -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry" -e "REGISTRY_HTTP_SECRET=ALongRandomSecretForRegistry" -e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd -v /opt/registry/certs:/certs:z -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt -e REGISTRY_HTTP_TLS_KEY=/certs/domain.key docker.io/library/registry:latest
[ "$?" == "0" ] || !!
systemctl enable --now registry
    1
    PULL_SECRET の場所は、設定に適した場所に置き換えます。

  2. スクリプトファイル registry.sh という名前を指定して保存します。スクリプトを実行すると、以下の情報がプルされます。

    • ハイパーバイザーのホスト名に基づくレジストリー名
    • 必要な認証情報およびユーザーアクセスの詳細

  3. 次のように実行フラグを追加して、パーミッションを調整します。 

    chmod u+x ${HOME}/registry.sh

  4. パラメーターを指定せずにスクリプトを実行するには、以下のコマンドを入力します。 

    ${HOME}/registry.sh

    このスクリプトはサーバーを起動します。

  5. このスクリプトは、管理目的で systemd サービスを使用します。スクリプトを管理する必要がある場合は、以下のコマンドを使用できます。 

    systemctl status
    systemctl start
    systemctl stop

レジストリーのルートフォルダーは /opt/registry ディレクトリー内にあり、次のサブディレクトリーが含まれています。

  • certs には TLS 証明書が含まれます。
  • auth には認証情報が含まれます。
  • data にはレジストリーイメージが含まれます。
  • conf にはレジストリー設定が含まれています。
1.7.12.5.4. IPv4 ネットワークの管理クラスターの設定

OpenShift Container Platform 管理クラスターを設定するには、dev-scripts を使用できます。または、仮想マシンをベースにしている場合は、kcli ツールを使用できます。以下は、kcli ツールに固有のものです。

  1. ハイパーバイザーで使用するために適切なネットワークの準備が完了していることを確認します。ネットワークは、管理クラスターとホステッドクラスターの両方をホストします。以下の kcli コマンドを入力します。 

    kcli create network -c 192.168.125.0/24 -P dhcp=false -P dns=false --domain dns.base.domain.name ipv4

    ここでは、以下のようになります。

    • -c は、ネットワークの CIDR を指定します。
    • -p dhcp=false は、設定した dnsmasq によって処理される DHCP を無効にするようにネットワークを設定します。
    • -P dns=false は、 DNS を無効にするようにネットワークを設定します。これも、設定した dnsmasq によって処理されます。
    • --domain は、検索するドメインを設定します。
    • dns.base.domain.name は DNS ベースドメイン名です。
    • ipv4 は、作成するネットワークの名前です。

  2. ネットワークを作成したら、以下の出力を確認します。 

    [root@hypershiftbm ~]# kcli list network
Listing Networks...
+---------+--------+---------------------+-------+------------------+------+
| Network |  Type  |         Cidr        |  Dhcp |      Domain      | Mode |
+---------+--------+---------------------+-------+------------------+------+
| default | routed |   192.168.122.0/24  |  True |     default      | nat  |
| ipv4    | routed |   192.168.125.0/24  | False | dns.base.domain.name | nat  |
| ipv6    | routed | 2620:52:0:1306::/64 | False | dns.base.domain.name | nat  |
+---------+--------+---------------------+-------+------------------+------+
    [root@hypershiftbm ~]# kcli info network ipv4
Providing information about network ipv4...
cidr: 192.168.125.0/24
dhcp: false
domain: dns.base.domain.name
mode: nat
plan: kvirt
type: routed

  3. OpenShift Container Platform 管理クラスターをデプロイできるように、プルシークレットと kcli プランファイルが配置されていることを確認します。

    1. プルシークレットが kcli プランと同じフォルダーにあり、プルシークレットファイルの名前が openshift_pull.json であることを確認します。

    2. OpenShift Container Platform 定義を含む kcli プランを mgmt-compact-hub-ipv4.yaml ファイルに追加します。ご使用の環境に合わせてファイルの内容を更新してください。 

      plan: hub-ipv4
force: true
version: nightly
tag: "4.x.y-x86_64" 1
cluster: "hub-ipv4"
domain: dns.base.domain.name
api_ip: 192.168.125.10
ingress_ip: 192.168.125.11
disconnected_url: registry.dns.base.domain.name:5000
disconnected_update: true
disconnected_user: dummy
disconnected_password: dummy
disconnected_operators_version: v4.14
disconnected_operators:
- name: metallb-operator
- name: lvms-operator
  channels:
  - name: stable-4.13
disconnected_extra_images:
- quay.io/user-name/trbsht:latest
- quay.io/user-name/hypershift:BMSelfManage-v4.14-rc-v3
- registry.redhat.io/openshift4/ose-kube-rbac-proxy:v4.10
dualstack: false
disk_size: 200
extra_disks: [200]
memory: 48000
numcpus: 16
ctlplanes: 3
workers: 0
manifests: extra-manifests
metal3: true
network: ipv4
users_dev: developer
users_devpassword: developer
users_admin: admin
users_adminpassword: admin
metallb_pool: ipv4-virtual-network
metallb_ranges:
- 192.168.125.150-192.168.125.190
metallb_autoassign: true
apps:
- users
- lvms-operator
- metallb-operator
vmrules:
- hub-bootstrap:
    nets:
    - name: ipv4
      mac: aa:aa:aa:aa:02:10
- hub-ctlplane-0:
    nets:
    - name: ipv4
      mac: aa:aa:aa:aa:02:01
- hub-ctlplane-1:
    nets:
    - name: ipv4
      mac: aa:aa:aa:aa:02:02
- hub-ctlplane-2:
    nets:
    - name: ipv4
      mac: aa:aa:aa:aa:02:03
    1
    4.x.y を、使用するサポートされている OpenShift Container Platform バージョンに置き換えます。

  4. 管理クラスターをプロビジョニングするには、以下のコマンドを入力します。 

    kcli create cluster openshift --pf mgmt-compact-hub-ipv4.yaml
1.7.12.5.4.1. 関連情報
  • kcli プランファイルのパラメーターの詳細は、kcli 公式ドキュメントの parameters.yml の作成 を参照してください。
1.7.12.5.5. IPv4 ネットワーク用の Web サーバーを設定する

ホステッドクラスターとしてデプロイする OpenShift Container Platform リリースに関連付けられた Red Hat Enterprise Linux CoreOS (RHCOS) イメージをホストするには、追加の Web サーバーを設定する必要があります。

Web サーバーを設定するには、以下の手順を実行します。

  1. 以下のコマンドを入力して、使用する OpenShift Container Platform リリースから openshift-install バイナリーを展開します。 

    oc adm -a ${LOCAL_SECRET_JSON} release extract --command=openshift-install "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}"

  2. 次のスクリプトを実行します。このスクリプトは、/opt/srv ディレクトリーにフォルダーを作成します。このフォルダーには、ワーカーノードをプロビジョニングするための RHCOS イメージが含まれています。 

    #!/bin/bash

WEBSRV_FOLDER=/opt/srv
ROOTFS_IMG_URL="$(./openshift-install coreos print-stream-json | jq -r '.architectures.x86_64.artifacts.metal.formats.pxe.rootfs.location')" 1
LIVE_ISO_URL="$(./openshift-install coreos print-stream-json | jq -r '.architectures.x86_64.artifacts.metal.formats.iso.disk.location')" 2

mkdir -p ${WEBSRV_FOLDER}/images
curl -Lk ${ROOTFS_IMG_URL} -o ${WEBSRV_FOLDER}/images/${ROOTFS_IMG_URL##*/}
curl -Lk ${LIVE_ISO_URL} -o ${WEBSRV_FOLDER}/images/${LIVE_ISO_URL##*/}
chmod -R 755 ${WEBSRV_FOLDER}/*

## Run Webserver
podman ps --noheading | grep -q websrv-ai
if [[ $? == 0 ]];then
    echo "Launching Registry pod..."
    /usr/bin/podman run --name websrv-ai --net host -v /opt/srv:/usr/local/apache2/htdocs:z quay.io/alosadag/httpd:p8080
fi
    1
    ROOTFS_IMG_URL 値は OpenShift CI Release ページにあります。
    2
    LIVE_ISO_URL 値は、OpenShift CI リリースページで確認できます。

ダウンロードが完了すると、コンテナーが実行され、Web サーバー上でイメージをホストします。このコンテナーは公式 HTTPd イメージのバリエーションを使用しているので、IPv6 ネットワークでの動作も可能になります。

1.7.12.5.6. IPv4 ネットワークのイメージミラーリングを設定する

イメージミラーリングは、registry.redhat.com や quay.io などの外部レジストリーからイメージを取得し、プライベートレジストリーに保存するプロセスです。

1.7.12.5.6.1. ミラーリングプロセスの完了

注: ミラーリングプロセスは、レジストリーサーバーの実行後に開始してください。

次の手順では、ImageSetConfiguration オブジェクトを使用するバイナリーである、oc-mirror ツールが使用されます。このファイルで、以下の情報を指定できます。

  • ミラーリングする OpenShift Container Platform バージョン。バージョンは quay.io にあります。
  • ミラーリングする追加の Operator。パッケージは個別に選択します。
  • リポジトリーに追加する追加のイメージ。

イメージのミラーリングを設定するには、以下の手順を実行します。

  1. ${HOME}/.docker/config.json ファイルが、ミラーリング元のレジストリーとイメージのプッシュ先のプライベートレジストリーで更新されていることを確認します。

  2. 次の例を使用して、ミラーリングに使用する 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.14
      minVersion: 4.x.y-x86_64 2
      maxVersion: 4.x.y-x86_64
      type: ocp
    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.14-rc-v3
  - name: registry.redhat.io/openshift4/ose-kube-rbac-proxy:v4.10
  operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.14
    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
    1
    dns.base.domain.name は DNS ベースドメイン名に置き換えます。
    2
    4.x.y を、使用するサポートされている OpenShift Container Platform バージョンに置き換えます。

  3. 次のコマンドを入力して、ミラーリングプロセスを開始します。 

    oc-mirror --source-skip-tls --config imagesetconfig.yaml docker://${REGISTRY}

    ミラーリングプロセスが完了すると、oc-mirror-workspace/results-XXXXXX/ という名前の新しいフォルダーが作成されます。このフォルダーには、ICSP と、ホステッドクラスターに適用するカタログソースが含まれます。

  4. oc adm release mirror コマンドを使用して、OpenShift Container Platform のナイトリーバージョンまたは CI バージョンをミラーリングします。以下のコマンドを入力します。 

    REGISTRY=registry.$(hostname --long):5000

oc adm release mirror \
  --from=registry.ci.openshift.org/ocp/release:4.x.y-x86_64 \
  --to=${REGISTRY}/openshift/release \
  --to-release-image=${REGISTRY}/openshift/release-images:4.x.y-x86_64

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

  5. 非接続ネットワークへのインストール の手順に従って、最新のマルチクラスターエンジン Operator イメージをミラーリングします。
1.7.12.5.6.2. 管理クラスターでのオブジェクトの適用

ミラーリングプロセスが完了したら、管理クラスターに 2 つのオブジェクトを適用する必要があります。

  • イメージコンテンツソースポリシー (ICSP) またはイメージダイジェストミラーセット (IDMS)
  • カタログソース

oc-mirror ツールを使用すると、出力アーティファクトは oc-mirror-workspace/results-XXXXXX/ という名前のフォルダーに保存されます。

ICSP または IDMS は、ノードを再起動せずに、各ノードで kubelet を再起動する MachineConfig 変更を開始します。ノードが READY としてマークされたら、新しく生成されたカタログソースを適用する必要があります。

カタログソースは、カタログイメージのダウンロードや処理を行い、そのイメージに含まれるすべての PackageManifests を取得するなど、openshift-marketplace Operator でアクションを開始します。

  1. 新しいソースを確認するには、新しい CatalogSource をソースとして使用して次のコマンドを実行します。 

    oc get packagemanifest

  2. アーティファクトを適用するには、次の手順を実行します。

    1. 次のコマンドを入力して、ImageContentSourcePolicy (ICSP) または IDMS アーティファクトを作成します。 

      oc apply -f oc-mirror-workspace/results-XXXXXX/imageContentSourcePolicy.yaml
    2. ノードの準備が完了するまで待ってから、次のコマンドを入力します。 
    oc apply -f catalogSource-XXXXXXXX-index.yaml

  3. OLM カタログをミラーリングし、ホステッドクラスターがミラーを指すように設定します。

    管理 (デフォルト) OLMCatalogPlacement モードを使用する場合、OLM カタログに使用されるイメージストリームは、管理クラスター上の ICSP からのオーバーライド情報で自動的に修正されません。

    1. OLM カタログが元の名前とタグを使用して内部レジストリーに適切にミラーリングされている場合は、hypershift.openshift.io/olm-catalogs-is-registry-overrides アノテーションを HostedCluster リソースに追加します。形式は "sr1=dr1,sr2=dr2 " です。ソースレジストリーの文字列はキーで、宛先のレジストリーは値になります。

    2. 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

      この場合、イメージストリームは作成されないため、Operator の更新を取り込むために内部ミラーの更新時に、アノテーションの値を更新する必要があります。

    注: 上書きメカニズムが必要な場合は、4 つのデフォルトのカタログソースの値 4 つすべてが必要です。

1.7.12.5.6.3. 関連情報
1.7.12.5.7. IPv4 ネットワーク用のマルチクラスターエンジン Operator をデプロイする

マルチクラスターエンジン Operator は、プロバイダー間でクラスターをデプロイメントする場合に重要な役割を果たします。Red Hat Advanced Cluster Management をすでにインストールしている場合は、マルチクラスターエンジン Operator は自動的にインストールされるため、インストールする必要はありません。

マルチクラスターエンジン Operator がインストールされていない場合は、次のドキュメントを参照して、前提条件とインストール手順を確認してください。

1.7.12.5.7.1. AgentServiceConfig リソースのデプロイ

AgentServiceConfig カスタムリソースは、マルチクラスターエンジン Operator の一部である Assisted Service アドオンの重要なコンポーネントです。このコンポーネントは、ベアメタルクラスターをデプロイメントします。アドオンが有効な場合に、AgentServiceConfig リソースをデプロイしてアドオンを設定します。

AgentServiceConfig リソースの設定に加えて、マルチクラスターエンジン Operator が非接続環境で適切に機能するように、追加の config map を含める必要があります。

  1. 次の config map を追加してカスタムレジストリーを設定します。これには、デプロイメントをカスタマイズするための非接続環境の情報が含まれています。 

    ---
apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-registries
  namespace: multicluster-engine
  labels:
    app: assisted-service
data:
  ca-bundle.crt: |
    -----BEGIN CERTIFICATE-----
    -----END CERTIFICATE-----
  registries.conf: |
    unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]

    [[registry]]
    prefix = ""
    location = "registry.redhat.io/openshift4"
    mirror-by-digest-only = true

    [[registry.mirror]]
      location = "registry.dns.base.domain.name:5000/openshift4" 1

    [[registry]]
    prefix = ""
    location = "registry.redhat.io/rhacm2"
    mirror-by-digest-only = true
    ...
    ...
    1
    dns.base.domain.name は DNS ベースドメイン名に置き換えます。

    オブジェクトには、以下の 2 つのフィールドが含まれます。

    • カスタム CA: このフィールドには、デプロイメントのさまざまなプロセスに読み込まれる認証局 (CA) が含まれます。
    • レジストリー: Registries.conf フィールドには、元のソースレジストリーではなくミラーレジストリーから使用する必要があるイメージと namespace に関する情報が含まれています。

  2. 次の例に示すように、AssistedServiceConfig オブジェクトを追加して、Assisted Service を設定します。 

    ---
apiVersion: agent-install.openshift.io/v1beta1
kind: AgentServiceConfig
metadata:
  annotations:
    unsupported.agent-install.openshift.io/assisted-service-configmap: assisted-service-config 1
  name: agent
  namespace: multicluster-engine
spec:
  mirrorRegistryRef:
    name: custom-registries 2
  databaseStorage:
    storageClassName: lvms-vg1
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: 10Gi
  filesystemStorage:
    storageClassName: lvms-vg1
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: 20Gi
  osImages: 3
  - cpuArchitecture: x86_64
    openshiftVersion: "4.14"
    rootFSUrl: http://registry.dns.base.domain.name:8080/images/rhcos-414.92.202308281054-0-live-rootfs.x86_64.img 4
    url: http://registry.dns.base.domain.name:8080/images/rhcos-414.92.202308281054-0-live.x86_64.iso
    version: 414.92.202308281054-0
    1
    metadata.annotations["unsupported.agent-install.openshift.io/assisted-service-configmap"] アノテーションは、Operator が動作をカスタマイズするために使用する config map 名を参照します。
    2
    spec.mirrorRegistryRef.name アノテーションは、Assisted Service Operator が使用する非接続のレジストリー情報を含む config map を指します。この config map は、デプロイメントプロセス中にこれらのリソースを追加します。
    3
    spec.osImages フィールドには、この Operator がデプロイできるさまざまなバージョンが含まれています。このフィールドは必須です。この例では、RootFS ファイルと LiveISO ファイルがすでにダウンロードされていることを前提としています。
    4
    rootFSUrl フィールド と url フィールドで、dns.base.domain.name を DNS ベースドメイン名に置き換えます。

  3. すべてのオブジェクトを 1 つのファイルに連結し、管理クラスターに適用し、これらのオブジェクトをデプロイします。起動するには、以下のコマンドを実行します。 

    oc apply -f agentServiceConfig.yaml

    このコマンドは、次の出力例に示すように、2 つの Pod をトリガーします。 

    assisted-image-service-0                               1/1     Running   2             11d 1
assisted-service-668b49548-9m7xw                       2/2     Running   5             11d 2
    1
    assisted-image-service Pod は、デプロイするクラスターごとにカスタマイズされた、Red Hat Enterprise Linux CoreOS (RHCOS) 起動イメージテンプレートを作成します。
    2
    assisted-service は Operator を参照します。
1.7.12.5.8. IPv4 ネットワークの TLS 証明書を設定する

オフライン環境で Hosted Control Plane を設定するプロセスに、いくつかの TLS 証明書が関与します。認証局 (CA) を管理クラスターに追加するには、OpenShift Container Platform コントロールプレーンおよびワーカーノード内の以下のファイルの内容を変更する必要があります。

  • /etc/pki/ca-trust/extracted/pem/
  • /etc/pki/ca-trust/source/anchors
  • /etc/pki/tls/certs/

CA を管理クラスターに追加するには、次の手順を実行します。

  1. OpenShift Container Platform の公式ドキュメントの CA バンドルの更新 の手順を完了します。この方法には、CA を OpenShift Container Platform ノードにデプロイする image-registry-operator の使用が含まれます。

  2. この方法が実際の状況に該当しない場合は、管理クラスター内の openshift-config namespace に user-ca-bundle という名前の config map が含まれているかどうかを確認してください。

    • namespace にその config map が含まれている場合は、次のコマンドを入力します。 

      ## REGISTRY_CERT_PATH=<PATH/TO/YOUR/CERTIFICATE/FILE>
export REGISTRY_CERT_PATH=/opt/registry/certs/domain.crt

oc create configmap user-ca-bundle -n openshift-config --from-file=ca-bundle.crt=${REGISTRY_CERT_PATH}

    • namespace にその config map が含まれていない場合は、以下のコマンドを入力します。 

      ## REGISTRY_CERT_PATH=<PATH/TO/YOUR/CERTIFICATE/FILE>
export REGISTRY_CERT_PATH=/opt/registry/certs/domain.crt
export TMP_FILE=$(mktemp)

oc get cm -n openshift-config user-ca-bundle -ojsonpath='{.data.ca-bundle\.crt}' > ${TMP_FILE}
echo >> ${TMP_FILE}
echo \#registry.$(hostname --long) >> ${TMP_FILE}
cat ${REGISTRY_CERT_PATH} >> ${TMP_FILE}
oc create configmap user-ca-bundle -n openshift-config --from-file=ca-bundle.crt=${TMP_FILE} --dry-run=client -o yaml | kubectl apply -f -
1.7.12.5.9. IPv4 ネットワークのホステッドクラスターをデプロイする

ホステッドクラスターは、コントロールプレーンと API エンドポイントが管理クラスターでホストされている OpenShift Container Platform クラスターです。ホステッドクラスターには、コントロールプレーンとそれに対応するデータプレーンが含まれます。

Red Hat Advanced Cluster Management のコンソールを使用してホステッドクラスターを作成できますが、次の手順ではマニフェストを使用するため、関連するアーティファクトをより柔軟に変更できます。

1.7.12.5.9.1. ホステッドクラスターオブジェクトのデプロイ

この手順では、次の値が使用されます。

  • HostedCluster name: hosted-ipv4
  • HostedCluster namespace: clusters
  • Disconnected: true
  • Network stack: IPv4

通常、HyperShift Operator は HostedControlPlane namespace を作成します。ただし、この場合は、HyperShift Operator が HostedCluster オブジェクトの調整を開始する前に、すべてのオブジェクトを含める必要があります。その後、Operator が調整プロセスを開始すると、所定の場所にあるすべてのオブジェクトを見つけることができます。

  1. namespace に関する次の情報を含めて、YAML ファイルを作成します。 

    ---
apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: null
  name: clusters-hosted-ipv4
spec: {}
status: {}
---
apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: null
  name: clusters
spec: {}
status: {}

  2. config map とシークレットに関する次の情報を含む YAML ファイルを作成し、HostedCluster デプロイメントに追加します。 

    ---
apiVersion: v1
data:
  ca-bundle.crt: |
    -----BEGIN CERTIFICATE-----
    -----END CERTIFICATE-----
kind: ConfigMap
metadata:
  name: user-ca-bundle
  namespace: clusters
---
apiVersion: v1
data:
  .dockerconfigjson: xxxxxxxxx
kind: Secret
metadata:
  creationTimestamp: null
  name: hosted-ipv4-pull-secret
  namespace: clusters
---
apiVersion: v1
kind: Secret
metadata:
  name: sshkey-cluster-hosted-ipv4
  namespace: clusters
stringData:
  id_rsa.pub: ssh-rsa xxxxxxxxx
---
apiVersion: v1
data:
  key: nTPtVBEt03owkrKhIdmSW8jrWRxU57KO/fnZa8oaG0Y=
kind: Secret
metadata:
  creationTimestamp: null
  name: hosted-ipv4-etcd-encryption-key
  namespace: clusters
type: Opaque

  3. RBAC ロールを含む YAML ファイルを作成し、Assisted Service エージェントが Hosted Control Plane と同じ HostedControlPlane namespace に配置し、引き続きクラスター API で管理されるようにします。 

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  creationTimestamp: null
  name: capi-provider-role
  namespace: clusters-hosted-ipv4
rules:
- apiGroups:
  - agent-install.openshift.io
  resources:
  - agents
  verbs:
  - '*'

  4. HostedCluster オブジェクトに関する情報を含む YAML ファイルを作成し、必要に応じて値を置き換えます。 

    apiVersion: hypershift.openshift.io/v1beta1
kind: HostedCluster
metadata:
  name: hosted-ipv4
  namespace: clusters
spec:
  additionalTrustBundle:
    name: "user-ca-bundle"
  olmCatalogPlacement: guest
  imageContentSources: 1
  - source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
    mirrors:
    - registry.dns.base.domain.name:5000/openshift/release
  - source: quay.io/openshift-release-dev/ocp-release
    mirrors:
    - registry.dns.base.domain.name:5000/openshift/release-images
  - mirrors:
  ...
  ...
  autoscaling: {}
  controllerAvailabilityPolicy: SingleReplica
  dns:
    baseDomain: dns.base.domain.name
  etcd:
    managed:
      storage:
        persistentVolume:
          size: 8Gi
        restoreSnapshotURL: null
        type: PersistentVolume
    managementType: Managed
  fips: false
  networking:
    clusterNetwork:
    - cidr: 10.132.0.0/14
    networkType: OVNKubernetes
    serviceNetwork:
    - cidr: 172.31.0.0/16
  platform:
    agent:
      agentNamespace: clusters-hosted-ipv4
    type: Agent
  pullSecret:
    name: hosted-ipv4-pull-secret
  release:
    image: registry.dns.base.domain.name:5000/openshift/release-images:4.x.y-x86_64
  secretEncryption:
    aescbc:
      activeKey:
        name: hosted-ipv4-etcd-encryption-key
    type: aescbc
  services:
  - service: APIServer
    servicePublishingStrategy:
      nodePort:
        address: api.hosted-ipv4.dns.base.domain.name
      type: NodePort
  - service: OAuthServer
    servicePublishingStrategy:
      nodePort:
        address: api.hosted-ipv4.dns.base.domain.name
      type: NodePort
  - service: OIDC
    servicePublishingStrategy:
      nodePort:
        address: api.hosted-ipv4.dns.base.domain.name
      type: NodePort
  - service: Konnectivity
    servicePublishingStrategy:
      nodePort:
        address: api.hosted-ipv4.dns.base.domain.name
      type: NodePort
  - service: Ignition
    servicePublishingStrategy:
      nodePort:
        address: api.hosted-ipv4.dns.base.domain.name
      type: NodePort
  sshKey:
    name: sshkey-cluster-hosted-ipv4
status:
  controlPlaneEndpoint:
    host: ""
    port: 0

    ここで、dns.base.domain.name は DNS ベースドメイン名であり、4.x.y は使用するサポートされている OpenShift Container Platform のバージョンです。

    1
    imageContentSources セクションには、ホステッドクラスター内のユーザーワークロードのミラー参照が含まれます。

  5. OpenShift Container Platform リリースの HyperShift Operator リリースを指すアノテーションを HostedCluster オブジェクトに追加します。

    1. 次のコマンドを入力して、イメージペイロードを取得します。 

      oc adm release info registry.dns.base.domain.name:5000/openshift-release-dev/ocp-release:4.x.y-x86_64 | grep hypershift

      ここで、dns.base.domain.name は DNS ベースドメイン名であり、4.x.y は使用するサポートされている OpenShift Container Platform のバージョンです。

    2. 以下の出力を参照してください。 

      hypershift                                     sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8

    3. OpenShift Container Platform Images namespace を使用して、次のコマンドを入力してダイジェストを確認します。 

      podman pull registry.dns.base.domain.name:5000/openshift-release-dev/ocp-v4.0-art-dev@sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8

      dns.base.domain.name は DNS ベースドメイン名です。

    4. 以下の出力を参照してください。 

      podman pull registry.dns.base.domain.name:5000/openshift/release@sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8
Trying to pull registry.dns.base.domain.name:5000/openshift/release@sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8...
Getting image source signatures
Copying blob d8190195889e skipped: already exists
Copying blob c71d2589fba7 skipped: already exists
Copying blob d4dc6e74b6ce skipped: already exists
Copying blob 97da74cc6d8f skipped: already exists
Copying blob b70007a560c9 done
Copying config 3a62961e6e done
Writing manifest to image destination
Storing signatures
3a62961e6ed6edab46d5ec8429ff1f41d6bb68de51271f037c6cb8941a007fde

    注: HostedCluster オブジェクトに設定されるリリースイメージでは、タグではなくダイジェストを使用する必要があります (例: quay.io/openshift-release-dev/ocp-release@sha256:e3ba11bd1e5e8ea5a0b36a75791c90f29afb0fdbe4125be4e48f69c76a5c47a0)。

  6. YAML ファイルで定義したすべてのオブジェクトを 1 つのファイルに連結し、管理クラスターに対して適用して作成します。起動するには、以下のコマンドを実行します。 

    oc apply -f 01-4.14-hosted_cluster-nodeport.yaml

  7. Hosted Control Plane の出力を参照してください。 

    NAME                                                  READY   STATUS    RESTARTS   AGE
capi-provider-5b57dbd6d5-pxlqc                        1/1     Running   0          3m57s
catalog-operator-9694884dd-m7zzv                      2/2     Running   0          93s
cluster-api-f98b9467c-9hfrq                           1/1     Running   0          3m57s
cluster-autoscaler-d7f95dd5-d8m5d                     1/1     Running   0          93s
cluster-image-registry-operator-5ff5944b4b-648ht      1/2     Running   0          93s
cluster-network-operator-77b896ddc-wpkq8              1/1     Running   0          94s
cluster-node-tuning-operator-84956cd484-4hfgf         1/1     Running   0          94s
cluster-policy-controller-5fd8595d97-rhbwf            1/1     Running   0          95s
cluster-storage-operator-54dcf584b5-xrnts             1/1     Running   0          93s
cluster-version-operator-9c554b999-l22s7              1/1     Running   0          95s
control-plane-operator-6fdc9c569-t7hr4                1/1     Running   0          3m57s
csi-snapshot-controller-785c6dc77c-8ljmr              1/1     Running   0          77s
csi-snapshot-controller-operator-7c6674bc5b-d9dtp     1/1     Running   0          93s
csi-snapshot-webhook-5b8584875f-2492j                 1/1     Running   0          77s
dns-operator-6874b577f-9tc6b                          1/1     Running   0          94s
etcd-0                                                3/3     Running   0          3m39s
hosted-cluster-config-operator-f5cf5c464-4nmbh        1/1     Running   0          93s
ignition-server-6b689748fc-zdqzk                      1/1     Running   0          95s
ignition-server-proxy-54d4bb9b9b-6zkg7                1/1     Running   0          95s
ingress-operator-6548dc758b-f9gtg                     1/2     Running   0          94s
konnectivity-agent-7767cdc6f5-tw782                   1/1     Running   0          95s
kube-apiserver-7b5799b6c8-9f5bp                       4/4     Running   0          3m7s
kube-controller-manager-5465bc4dd6-zpdlk              1/1     Running   0          44s
kube-scheduler-5dd5f78b94-bbbck                       1/1     Running   0          2m36s
machine-approver-846c69f56-jxvfr                      1/1     Running   0          92s
oauth-openshift-79c7bf44bf-j975g                      2/2     Running   0          62s
olm-operator-767f9584c-4lcl2                          2/2     Running   0          93s
openshift-apiserver-5d469778c6-pl8tj                  3/3     Running   0          2m36s
openshift-controller-manager-6475fdff58-hl4f7         1/1     Running   0          95s
openshift-oauth-apiserver-dbbc5cc5f-98574             2/2     Running   0          95s
openshift-route-controller-manager-5f6997b48f-s9vdc   1/1     Running   0          95s
packageserver-67c87d4d4f-kl7qh                        2/2     Running   0          93s

  8. ホステッドクラスターの出力を確認します。 

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

次に、NodePool オブジェクトを作成します。

1.7.12.5.9.2. ホステッドクラスターの NodePool オブジェクトの作成

NodePool は、ホステッドクラスターに関連付けられたスケーラブルなワーカーノードのセットです。NodePool マシンアーキテクチャーは特定のプール内で一貫性を保ち、コントロールプレーンのマシンアーキテクチャーから独立しています。

  1. NodePool オブジェクトに関する次の情報を含む YAML ファイルを作成し、必要に応じて値を置き換えます。 

    apiVersion: hypershift.openshift.io/v1beta1
kind: NodePool
metadata:
  creationTimestamp: null
  name: hosted-ipv4
  namespace: clusters
spec:
  arch: amd64
  clusterName: hosted-ipv4
  management:
    autoRepair: false 1
    upgradeType: InPlace 2
  nodeDrainTimeout: 0s
  platform:
    type: Agent
  release:
    image: registry.dns.base.domain.name:5000/openshift/release-images:4.x.y-x86_64 3
  replicas: 0
status:
  replicas: 0 4
    1
    ノードが削除された場合、ノードは再作成されないため、autoRepair フィールドは false に設定されます。
    2
    upgradeType は InPlace に設定されます。これは、アップグレード中に同じベアメタルノードが再利用されることを示します。
    3
    この NodePool に含まれるすべてのノードは、OpenShift Container Platform バージョン 4.x.y-x86_64 に基づいています。dns.base.domain.name を DNS ベースドメイン名に置き換え、4.x.y を使用したいサポートされている OpenShift Container Platform バージョンに置き換えます。
    4
    replicas の値は 0 に設定されているため、必要に応じてスケールを変更できます。すべての手順が完了するまで、NodePool レプリカを 0 に保つことが重要です。

  2. 次のコマンドを入力して、NodePool オブジェクトを作成します。 

    oc apply -f 02-nodepool.yaml

  3. 出力を参照してください。 

    NAMESPACE   NAME          CLUSTER   DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION                              UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
clusters    hosted-ipv4   hosted    0                               False         False        4.x.y-x86_64

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

次に、InfraEnv リソースを作成します。

1.7.12.5.9.3. ホステッドクラスターの InfraEnv リソースの作成

InfraEnv リソースは、pullSecretRef や sshAuthorizedKey などの重要な詳細を含む Assisted Service オブジェクトです。これらの詳細は、ホステッドクラスター用にカスタマイズされた Red Hat Enterprise Linux CoreOS (RHCOS) ブートイメージを作成するために使用されます。

  1. InfraEnv リソースに関する次の情報を含めて YAML ファイルを作成し、必要に応じて値を置き換えます。 

    ---
apiVersion: agent-install.openshift.io/v1beta1
kind: InfraEnv
metadata:
  name: hosted-ipv4
  namespace: clusters-hosted-ipv4
spec:
  pullSecretRef: 1
    name: pull-secret
  sshAuthorizedKey: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDk7ICaUE+/k4zTpxLk4+xFdHi4ZuDi5qjeF52afsNkw0w/glILHhwpL5gnp5WkRuL8GwJuZ1VqLC9EKrdmegn4MrmUlq7WTsP0VFOZFBfq2XRUxo1wrRdor2z0Bbh93ytR+ZsDbbLlGngXaMa0Vbt+z74FqlcajbHTZ6zBmTpBVq5RHtDPgKITdpE1fongp7+ZXQNBlkaavaqv8bnyrP4BWahLP4iO9/xJF9lQYboYwEEDzmnKLMW1VtCE6nJzEgWCufACTbxpNS7GvKtoHT/OVzw8ArEXhZXQUS1UY8zKsX2iXwmyhw5Sj6YboA8WICs4z+TrFP89LmxXY0j6536TQFyRz1iB4WWvCbH5n6W+ABV2e8ssJB1AmEy8QYNwpJQJNpSxzoKBjI73XxvPYYC/IjPFMySwZqrSZCkJYqQ023ySkaQxWZT7in4KeMu7eS2tC+Kn4deJ7KwwUycx8n6RHMeD8Qg9flTHCv3gmab8JKZJqN3hW1D378JuvmIX4V0= 2
    1
    pullSecretRef は、プルシークレットが使用される InfraEnv と同じ namespace 内の config map を参照します。
    2
    sshAuthorizedKey は、ブートイメージに配置される SSH 公開鍵を表します。SSH 鍵を使用すると、core ユーザーとしてワーカーノードにアクセスできます。

  2. 次のコマンドを入力して、InfraEnv リソースを作成します。 

    oc apply -f 03-infraenv.yaml

  3. 以下の出力を参照してください。 

    NAMESPACE              NAME     ISO CREATED AT
clusters-hosted-ipv4   hosted   2023-09-11T15:14:10Z

次に、ワーカーノードを作成します。

1.7.12.5.9.4. ホステッドクラスター用のワーカーノードの作成

ベアメタルプラットフォームで作業している場合、BareMetalHost の詳細が正しく設定されていることを確認するためにワーカーノードを作成することが重要です。

仮想マシンを使用している場合は、次の手順を実行して、Metal3 Operator が使用する空のワーカーノードを作成できます。これには、kcli を使用します。

  1. ワーカーノードを作成するのが初めてではない場合は、まず以前の設定を削除する必要があります。これには、次のコマンドを入力してプランを削除します。 

    kcli delete plan hosted-ipv4
    1. プランを削除するかどうかを確認するプロンプトが表示されたら、y と入力します。
    2. プランが削除されたことを示すメッセージが表示されることを確認します。

  2. 次のコマンドを入力して仮想マシンを作成します。 

    kcli create vm -P start=False -P uefi_legacy=true -P plan=hosted-ipv4 -P memory=8192 -P numcpus=16 -P disks=[200,200] -P nets=["{\"name\": \"ipv4\", \"mac\": \"aa:aa:aa:aa:02:11\"}"] -P uuid=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0211 -P name=hosted-ipv4-worker0
    kcli create vm -P start=False -P uefi_legacy=true -P plan=hosted-ipv4 -P memory=8192 -P numcpus=16 -P disks=[200,200] -P nets=["{\"name\": \"ipv4\", \"mac\": \"aa:aa:aa:aa:02:12\"}"] -P uuid=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0212 -P name=hosted-ipv4-worker1
    kcli create vm -P start=False -P uefi_legacy=true -P plan=hosted-ipv4 -P memory=8192 -P numcpus=16 -P disks=[200,200] -P nets=["{\"name\": \"ipv4\", \"mac\": \"aa:aa:aa:aa:02:13\"}"] -P uuid=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0213 -P name=hosted-ipv4-worker2
    systemctl restart ksushy

    ここでは、以下のようになります。

    • start=False は、仮想マシン (VM) が作成時に自動的に起動しないことを意味します。
    • uefi_legacy=true は、以前の UEFI 実装との互換性を確保するために UEFI レガシーブートを使用することを意味します。
    • plan=hosted-dual は、マシンのグループをクラスターとして識別するプラン名を示します。
    • memory=8192 および numcpus=16 は、RAM や CPU などの仮想マシンのリソースを指定するパラメーターです。
    • disks=[200,200] は、VM 内に 2 つのシンプロビジョニングディスクを作成していることを示します。
    • nets=[{"name": "dual", "mac": "aa:aa:aa:aa:02:13"}] は、接続するネットワーク名やプライマリーインターフェイスの MAC アドレスなど、ネットワークの詳細です。
    • restart ksushy は、ksushy ツールを再起動して、追加した VM をツールが確実に検出できるようにします。

  3. 結果の出力を確認します。 

    +---------------------+--------+-------------------+----------------------------------------------------+-------------+---------+
|         Name        | Status |         Ip        |                       Source                       |     Plan    | Profile |
+---------------------+--------+-------------------+----------------------------------------------------+-------------+---------+
|    hosted-worker0   |  down  |                   |                                                    | hosted-ipv4 |  kvirt  |
|    hosted-worker1   |  down  |                   |                                                    | hosted-ipv4 |  kvirt  |
|    hosted-worker2   |  down  |                   |                                                    | hosted-ipv4 |  kvirt  |
+---------------------+--------+-------------------+----------------------------------------------------+-------------+---------+

次に、ホステッドクラスターのベアメタルホストを作成します。

1.7.12.5.9.5. ホステッドクラスターのベアメタルホスト作成

ベアメタルホスト は、物理的な詳細と論理詳細を含む openshift-machine-api オブジェクトで、Metal3 Operator によって識別できるようになっています。これらの詳細は、agents と呼ばれる他の Assisted Service オブジェクトに関連付けられています。

重要: ベアメタルホストと移行先ノードを作成する前に、仮想マシンを作成する必要があります。

ベアメタルホストを作成するには、以下の手順を実行します。

  1. 次の情報を使用して YAML ファイルを作成します。

    注記: ベアメタルホストの認証情報を保持するシークレットが 1 つ以上あるため、ワーカーノードごとに少なくとも 2 つのオブジェクトを作成する必要があります。 

    ---
apiVersion: v1
kind: Secret
metadata:
  name: hosted-ipv4-worker0-bmc-secret
  namespace: clusters-hosted-ipv4
data:
  password: YWRtaW4=
  username: YWRtaW4=
type: Opaque
---
apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: hosted-ipv4-worker0
  namespace: clusters-hosted-ipv4
  labels:
    infraenvs.agent-install.openshift.io: hosted-ipv4 1
  annotations:
    inspect.metal3.io: disabled
    bmac.agent-install.openshift.io/hostname: hosted-ipv4-worker0 2
spec:
  automatedCleaningMode: disabled 3
  bmc:
    disableCertificateVerification: true 4
    address: redfish-virtualmedia://[192.168.125.1]:9000/redfish/v1/Systems/local/hosted-ipv4-worker0 5
    credentialsName: hosted-ipv4-worker0-bmc-secret 6
  bootMACAddress: aa:aa:aa:aa:02:11 7
  online: true 8
    1
    infraenvs.agent-install.openshift.io は、Assisted Installer オブジェクトと BareMetalHost オブジェクト間のリンクとして機能します。
    2
    bmac.agent-install.openshift.io/hostname は、デプロイメント中に採用されるノード名を表します。
    3
    automatedCleaningMode は、ノードが Metal3 Operator によって消去されるのを防ぎます。
    4
    disableCertificateVerification は true に設定され、クライアントから証明書の検証がバイパスされます。
    5
    address は、ワーカーノードのベースボード管理コントローラー (BMC) アドレスを示します。
    6
    credentialsName は、ユーザーとパスワードの認証情報が保存されるシークレットを指します。
    7
    bootMACAddress は、ノードの起動元のインターフェイス MACAddress を示します。
    8
    online は、BareMetalHost オブジェクトが作成された後のノードの状態を定義します。

  2. 次のコマンドを入力して、BareMetalHost オブジェクトをデプロイします。 

    oc apply -f 04-bmh.yaml

    プロセス中に、次の出力が確認できます。

    • この出力は、プロセスがノードに到達しようとしていることを示しています。 

      NAMESPACE         NAME             STATE         CONSUMER   ONLINE   ERROR   AGE
clusters-hosted   hosted-worker0   registering              true             2s
clusters-hosted   hosted-worker1   registering              true             2s
clusters-hosted   hosted-worker2   registering              true             2s

    • この出力は、ノードが起動していることを示しています。 

      NAMESPACE         NAME             STATE          CONSUMER   ONLINE   ERROR   AGE
clusters-hosted   hosted-worker0   provisioning              true             16s
clusters-hosted   hosted-worker1   provisioning              true             16s
clusters-hosted   hosted-worker2   provisioning              true             16s
    • この出力は、ノードが正常に起動したことを示しています。 
    NAMESPACE         NAME             STATE         CONSUMER   ONLINE   ERROR   AGE
clusters-hosted   hosted-worker0   provisioned              true             67s
clusters-hosted   hosted-worker1   provisioned              true             67s
clusters-hosted   hosted-worker2   provisioned              true             67s

  3. ノードが起動したら、次の例に示すように、namespace のエージェントに注目してください。 

    NAMESPACE         NAME                                   CLUSTER   APPROVED   ROLE          STAGE
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0411             true       auto-assign
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0412             true       auto-assign
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0413             true       auto-assign

    エージェントは、インストールに使用できるノードを表します。ホステッドクラスターにノードを割り当てるには、ノードプールをスケールアップします。

1.7.12.5.9.6. ノードプールのスケールアップ

ベアメタルホストを作成すると、そのステータスが Registering Provisioning、Provisioned に変わります。ノードは、エージェントの LiveISO と、agent という名前のデフォルトの Pod で始まります。このエージェントは、Assisted Service Operator から OpenShift Container Platform ペイロードをインストールする指示を受け取ります。

  1. ノードプールをスケールアップするには、次のコマンドを入力します。 

    oc -n clusters scale nodepool hosted-ipv4 --replicas 3

  2. スケーリングプロセスが完了すると、エージェントがホステッドクラスターに割り当てられていることがわかります。 

    NAMESPACE         NAME                                   CLUSTER   APPROVED   ROLE          STAGE
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0411   hosted    true       auto-assign
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0412   hosted    true       auto-assign
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0413   hosted    true       auto-assign

  3. また、ノードプールレプリカが設定されていることにも注意してください。 

    NAMESPACE   NAME     CLUSTER   DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION                              UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
clusters    hosted   hosted    3                               False         False        4.x.y-x86_64                                      Minimum availability requires 3 replicas, current 0 available

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

  4. ノードがクラスターに参加するまで待ちます。プロセス中に、エージェントはステージとステータスに関する最新情報を提供します。

次に、ホステッドクラスターのデプロイメントを監視します。

1.7.12.5.10. IPv4 ネットワーク用のホステッドクラスターのデプロイメントの完了

ホステッドクラスターのデプロイメントは、コントロールプレーンとデータプレーンの 2 つの観点から監視できます。

1.7.12.5.10.1. コントロールプレーンの監視

ホステッドクラスターのデプロイメント中に、次のコマンドを入力してコントロールプレーンを監視できます。 

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;"

これらのコマンドは、次のアーティファクトに関する情報を提供します。

  • HyperShift Operator
  • HostedControlPlane Pod
  • ベアメタルホスト
  • エージェント
  • InfraEnv リソース
  • HostedCluster および NodePool リソース
1.7.12.5.10.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"

これらのコマンドは、次のアーティファクトに関する情報を提供します。

  • クラスターのバージョン
  • ノード (特にノードがクラスターに参加したかどうかについて)
  • クラスター Operator

1.7.12.6. IPv6 ネットワーク上での Hosted Control Plane の設定

IPv6 ネットワーク設定は、現在 disconnected として指定されます。この指定の主な理由は、リモートレジストリーが IPv6 では機能しないためです。

IPv6 ネットワーク上で Hosted Control Plane を設定するには、次の手順を確認してください。

  1. IPv6 ネットワーク用のハイパーバイザーを設定する
  2. IPv6 ネットワークの DNS を設定する
  3. IPv6 ネットワーク用のレジストリーをデプロイする
  4. IPv6 ネットワークの管理クラスターを設定する
  5. IPv6 ネットワーク用の Web サーバーを設定する
  6. IPv6 ネットワークのイメージミラーリングを設定する
  7. IPv6 ネットワーク用のマルチクラスターエンジン Operator をデプロイする
  8. IPv6 ネットワークの TLS 証明書を設定する
  9. IPv6 ネットワークのホステッドクラスターをデプロイする
  10. IPv6 ネットワークのデプロイメントを終了する
1.7.12.6.1. IPv6 ネットワーク用のハイパーバイザーを設定する

以下の情報は、仮想マシン環境にのみ適用されます。

1.7.12.6.1.1. 仮想 OpenShift Container Platform クラスターのパッケージへのアクセスおよびデプロイ

  1. 仮想 OpenShift Container Platform 管理クラスターをデプロイするには、以下のコマンドを入力して必要なパッケージにアクセスします。 

    sudo dnf install dnsmasq radvd vim golang podman bind-utils net-tools httpd-tools tree htop strace tmux -y

  2. 次のコマンドを入力して、Podman サービスを有効にして起動します。 

    systemctl enable --now podman

  3. kcli を使用して OpenShift Container Platform 管理クラスターおよびその他の仮想コンポーネントをデプロイするには、以下のコマンドを入力してハイパーバイザーをインストールおよび設定します。 

    sudo yum -y install libvirt libvirt-daemon-driver-qemu qemu-kvm
    sudo usermod -aG qemu,libvirt $(id -un)
    sudo newgrp libvirt
    sudo systemctl enable --now libvirtd
    sudo dnf -y copr enable karmab/kcli
    sudo dnf -y install kcli
    sudo kcli create pool -p /var/lib/libvirt/images default
    kcli create host kvm -H 127.0.0.1 local
    sudo setfacl -m u:$(id -un):rwx /var/lib/libvirt/images
    kcli create network  -c 192.168.122.0/24 default
1.7.12.6.1.2. ネットワークマネージャーディスパッチャーの有効化

  1. ネットワークマネージャーのディスパッチャーを有効にして、仮想マシンが必要なドメイン、ルート、およびレジストリーを解決できるようにします。ネットワークマネージャーディスパッチャーを有効にするには、/etc/NetworkManager/dispatcher.d/ ディレクトリーに次の内容を含む forcedns という名前のスクリプトを作成し、環境に合わせて必要に応じて値を置き換えます。 

    #!/bin/bash

export IP="2620:52:0:1306::1" 1
export BASE_RESOLV_CONF="/run/NetworkManager/resolv.conf"

if ! [[ `grep -q "$IP" /etc/resolv.conf` ]]; then
export TMP_FILE=$(mktemp /etc/forcedns_resolv.conf.XXXXXX)
cp $BASE_RESOLV_CONF $TMP_FILE
chmod --reference=$BASE_RESOLV_CONF $TMP_FILE
sed -i -e "s/dns.base.domain.name//" -e "s/search /& dns.base.domain.name /" -e "0,/nameserver/s/nameserver/& $IP\n&/" $TMP_FILE 2
mv $TMP_FILE /etc/resolv.conf
fi
echo "ok"
    1
    OpenShift Container Platform 管理クラスターをホストするハイパーバイザーインターフェイスの IP アドレスを指すように IP 変数を変更します。
    2
    dns.base.domain.name は DNS ベースドメイン名に置き換えます。

  2. ファイルを作成したら、次のコマンドを入力してパーミッションを追加します。 

    chmod 755 /etc/NetworkManager/dispatcher.d/forcedns
  3. スクリプトを実行し、出力が ok を返すことを確認します。
1.7.12.6.1.3. BMC アクセスの設定

  1. 仮想マシンのベースボード管理コントローラー (BMC) をシミュレートするように ksushy を設定します。次のコマンドを入力します。 

    sudo dnf install python3-pyOpenSSL.noarch python3-cherrypy -y
    kcli create sushy-service --ssl --ipv6 --port 9000
    sudo systemctl daemon-reload
    systemctl enable --now ksushy

  2. 次のコマンドを入力して、サービスが正しく機能しているかどうかをテストします。 

    systemctl status ksushy
1.7.12.6.1.4. 接続を許可するためのハイパーバイザーシステムの設定

開発環境で作業している場合は、環境内の各種仮想ネットワークを介したさまざまなタイプの接続を許可するようにハイパーバイザーシステムを設定します。

注: 実稼働環境で作業している場合は、安全な環境を維持するために、firewalld サービスの適切なルールを確立し、SELinux ポリシーを設定する必要があります。

  • SELinux の場合は、次のコマンドを入力します。 

    sed -i s/^SELINUX=.*$/SELINUX=permissive/ /etc/selinux/config; setenforce 0

  • firewalld の場合は、次のコマンドを入力します。 

    systemctl disable --now firewalld

  • libvirtd の場合は、以下のコマンドを入力します。 

    systemctl restart libvirtd
    systemctl enable --now libvirtd

次に、環境に合わせて DNS を設定します。

1.7.12.6.1.5. 関連情報
1.7.12.6.2. IPv6 ネットワークの DNS を設定する

この手順は、仮想環境とベアメタル環境の両方で、オフライン環境とオンライン環境の両方で必須です。仮想環境とベアメタル環境の主な違いは、リソースを設定する場所にあります。ベアメタル環境では、dnsmasq のような軽量のソリューションではなく、Bind のようなソリューションを使用してください。

次にレジストリーをデプロイします。

1.7.12.6.3. IPv6 ネットワーク用のレジストリーをデプロイする

開発環境の場合は、Podman コンテナーを使用して、小規模な自己ホスト型レジストリーをデプロイします。実稼働環境では、Red Hat Quay、Nexus、Artifactory などのエンタープライズでホストされるレジストリーを使用します。

Podman を使用して小規模なレジストリーをデプロイするには、以下の手順を実行します。

  1. 特権ユーザーとして ${HOME} ディレクトリーにアクセスし、次のスクリプトを作成します。 

    #!/usr/bin/env bash

set -euo pipefail

PRIMARY_NIC=$(ls -1 /sys/class/net | grep -v podman | head -1)
export PATH=/root/bin:$PATH
export PULL_SECRET="/root/baremetal/hub/openshift_pull.json" 1

if [[ ! -f $PULL_SECRET ]];then
  echo "Pull Secret not found, exiting..."
  exit 1
fi

dnf -y install podman httpd httpd-tools jq skopeo libseccomp-devel
export IP=$(ip -o addr show $PRIMARY_NIC | head -1 | awk '{print $4}' | cut -d'/' -f1)
REGISTRY_NAME=registry.$(hostname --long)
REGISTRY_USER=dummy
REGISTRY_PASSWORD=dummy
KEY=$(echo -n $REGISTRY_USER:$REGISTRY_PASSWORD | base64)
echo "{\"auths\": {\"$REGISTRY_NAME:5000\": {\"auth\": \"$KEY\", \"email\": \"sample-email@domain.ltd\"}}}" > /root/disconnected_pull.json
mv ${PULL_SECRET} /root/openshift_pull.json.old
jq ".auths += {\"$REGISTRY_NAME:5000\": {\"auth\": \"$KEY\",\"email\": \"sample-email@domain.ltd\"}}" < /root/openshift_pull.json.old > $PULL_SECRET
mkdir -p /opt/registry/{auth,certs,data,conf}
cat <<EOF > /opt/registry/conf/config.yml
version: 0.1
log:
  fields:
    service: registry
storage:
  cache:
    blobdescriptor: inmemory
  filesystem:
    rootdirectory: /var/lib/registry
  delete:
    enabled: true
http:
  addr: :5000
  headers:
    X-Content-Type-Options: [nosniff]
health:
  storagedriver:
    enabled: true
    interval: 10s
    threshold: 3
compatibility:
  schema1:
    enabled: true
EOF
openssl req -newkey rsa:4096 -nodes -sha256 -keyout /opt/registry/certs/domain.key -x509 -days 3650 -out /opt/registry/certs/domain.crt -subj "/C=US/ST=Madrid/L=San Bernardo/O=Karmalabs/OU=Guitar/CN=$REGISTRY_NAME" -addext "subjectAltName=DNS:$REGISTRY_NAME"
cp /opt/registry/certs/domain.crt /etc/pki/ca-trust/source/anchors/
update-ca-trust extract
htpasswd -bBc /opt/registry/auth/htpasswd $REGISTRY_USER $REGISTRY_PASSWORD
podman create --name registry --net host --security-opt label=disable --replace -v /opt/registry/data:/var/lib/registry:z -v /opt/registry/auth:/auth:z -v /opt/registry/conf/config.yml:/etc/docker/registry/config.yml -e "REGISTRY_AUTH=htpasswd" -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry" -e "REGISTRY_HTTP_SECRET=ALongRandomSecretForRegistry" -e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd -v /opt/registry/certs:/certs:z -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt -e REGISTRY_HTTP_TLS_KEY=/certs/domain.key docker.io/library/registry:latest
[ "$?" == "0" ] || !!
systemctl enable --now registry
    1
    PULL_SECRET の場所は、設定に適した場所に置き換えます。

  2. スクリプトファイル registry.sh という名前を指定して保存します。スクリプトを実行すると、以下の情報がプルされます。

    • ハイパーバイザーのホスト名に基づくレジストリー名
    • 必要な認証情報およびユーザーアクセスの詳細

  3. 次のように実行フラグを追加して、パーミッションを調整します。 

    chmod u+x ${HOME}/registry.sh

  4. パラメーターを指定せずにスクリプトを実行するには、以下のコマンドを入力します。 

    ${HOME}/registry.sh

    このスクリプトはサーバーを起動します。

  5. このスクリプトは、管理目的で systemd サービスを使用します。スクリプトを管理する必要がある場合は、以下のコマンドを使用できます。 

    systemctl status
    systemctl start
    systemctl stop

レジストリーのルートフォルダーは /opt/registry ディレクトリー内にあり、次のサブディレクトリーが含まれています。

  • certs には TLS 証明書が含まれます。
  • auth には認証情報が含まれます。
  • data にはレジストリーイメージが含まれます。
  • conf にはレジストリー設定が含まれています。
1.7.12.6.4. IPv6 ネットワークの管理クラスターの設定

OpenShift Container Platform 管理クラスターを設定するには、dev-scripts を使用できます。または、仮想マシンをベースにしている場合は、kcli ツールを使用できます。以下は、kcli ツールに固有のものです。

  1. ハイパーバイザーで使用するために適切なネットワークの準備が完了していることを確認します。ネットワークは、管理クラスターとホステッドクラスターの両方をホストします。以下の kcli コマンドを入力します。 

    kcli create network -c 2620:52:0:1305::0/64 -P dhcp=false -P dns=false --domain dns.base.domain.name --nodhcp ipv6

    ここでは、以下のようになります。

    • -c は、ネットワークの CIDR を指定します。
    • -p dhcp=false は、設定した dnsmasq によって処理される DHCP を無効にするようにネットワークを設定します。
    • -P dns=false は、 DNS を無効にするようにネットワークを設定します。これも、設定した dnsmasq によって処理されます。
    • --domain は、検索するドメインを設定します。
    • dns.base.domain.name は DNS ベースドメイン名です。
    • ipv6 は、作成するネットワークの名前です。

  2. ネットワークを作成したら、以下の出力を確認します。 

    [root@hypershiftbm ~]# kcli list network
Listing Networks...
+---------+--------+---------------------+-------+------------------+------+
| Network |  Type  |         Cidr        |  Dhcp |      Domain      | Mode |
+---------+--------+---------------------+-------+------------------+------+
| default | routed |   192.168.122.0/24  |  True |     default      | nat  |
| ipv4    | routed |   192.168.125.0/24  | False | dns.base.domain.name | nat  |
| ipv4    | routed | 2620:52:0:1305::/64 | False | dns.base.domain.name | nat  |
+---------+--------+---------------------+-------+------------------+------+
    [root@hypershiftbm ~]# kcli info network ipv6
Providing information about network ipv6...
cidr: 2620:52:0:1305::/64
dhcp: false
domain: dns.base.domain.name
mode: nat
plan: kvirt
type: routed

  3. OpenShift Container Platform 管理クラスターをデプロイできるように、プルシークレットと kcli プランファイルが配置されていることを確認します。

    1. プルシークレットが kcli プランと同じフォルダーにあり、プルシークレットファイルの名前が openshift_pull.json であることを確認します。
    2. OpenShift Container Platform 定義を含む kcli プランを mgmt-compact-hub-ipv6.yaml ファイルに追加します。ご使用の環境に合わせてファイルの内容を更新してください。 
    plan: hub-ipv6
force: true
version: nightly
tag: "4.x.y-x86_64"
cluster: "hub-ipv6"
ipv6: true
domain: dns.base.domain.name
api_ip: 2620:52:0:1305::2
ingress_ip: 2620:52:0:1305::3
disconnected_url: registry.dns.base.domain.name:5000
disconnected_update: true
disconnected_user: dummy
disconnected_password: dummy
disconnected_operators_version: v4.14
disconnected_operators:
- name: metallb-operator
- name: lvms-operator
  channels:
  - name: stable-4.13
disconnected_extra_images:
- quay.io/user-name/trbsht:latest
- quay.io/user-name/hypershift:BMSelfManage-v4.14-rc-v3
- registry.redhat.io/openshift4/ose-kube-rbac-proxy:v4.10
dualstack: false
disk_size: 200
extra_disks: [200]
memory: 48000
numcpus: 16
ctlplanes: 3
workers: 0
manifests: extra-manifests
metal3: true
network: ipv6
users_dev: developer
users_devpassword: developer
users_admin: admin
users_adminpassword: admin
metallb_pool: ipv6-virtual-network
metallb_ranges:
- 2620:52:0:1305::150-2620:52:0:1305::190
metallb_autoassign: true
apps:
- users
- lvms-operator
- metallb-operator
vmrules:
- hub-bootstrap:
    nets:
    - name: ipv6
      mac: aa:aa:aa:aa:03:10
- hub-ctlplane-0:
    nets:
    - name: ipv6
      mac: aa:aa:aa:aa:03:01
- hub-ctlplane-1:
    nets:
    - name: ipv6
      mac: aa:aa:aa:aa:03:02
- hub-ctlplane-2:
    nets:
    - name: ipv6
      mac: aa:aa:aa:aa:03:03

  4. 管理クラスターをプロビジョニングするには、以下のコマンドを入力します。 

    kcli create cluster openshift --pf mgmt-compact-hub-ipv6.yaml
1.7.12.6.4.1. 関連情報
  • kcli プランファイルのパラメーターの詳細は、kcli 公式ドキュメントの parameters.yml の作成 を参照してください。
1.7.12.6.5. IPv6 ネットワーク用の Web サーバーを設定する

ホステッドクラスターとしてデプロイする OpenShift Container Platform リリースに関連付けられた Red Hat Enterprise Linux CoreOS (RHCOS) イメージをホストするには、追加の Web サーバーを設定する必要があります。

Web サーバーを設定するには、以下の手順を実行します。

  1. 以下のコマンドを入力して、使用する OpenShift Container Platform リリースから openshift-install バイナリーを展開します。 

    oc adm -a ${LOCAL_SECRET_JSON} release extract --command=openshift-install "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}"

  2. 次のスクリプトを実行します。このスクリプトは、/opt/srv ディレクトリーにフォルダーを作成します。このフォルダーには、ワーカーノードをプロビジョニングするための RHCOS イメージが含まれています。 

    #!/bin/bash

WEBSRV_FOLDER=/opt/srv
ROOTFS_IMG_URL="$(./openshift-install coreos print-stream-json | jq -r '.architectures.x86_64.artifacts.metal.formats.pxe.rootfs.location')" 1
LIVE_ISO_URL="$(./openshift-install coreos print-stream-json | jq -r '.architectures.x86_64.artifacts.metal.formats.iso.disk.location')" 2

mkdir -p ${WEBSRV_FOLDER}/images
curl -Lk ${ROOTFS_IMG_URL} -o ${WEBSRV_FOLDER}/images/${ROOTFS_IMG_URL##*/}
curl -Lk ${LIVE_ISO_URL} -o ${WEBSRV_FOLDER}/images/${LIVE_ISO_URL##*/}
chmod -R 755 ${WEBSRV_FOLDER}/*

## Run Webserver
podman ps --noheading | grep -q websrv-ai
if [[ $? == 0 ]];then
    echo "Launching Registry pod..."
    /usr/bin/podman run --name websrv-ai --net host -v /opt/srv:/usr/local/apache2/htdocs:z quay.io/alosadag/httpd:p8080
fi
    1
    ROOTFS_IMG_URL 値は OpenShift CI Release ページにあります。
    2
    LIVE_ISO_URL 値は、OpenShift CI リリースページで確認できます。

ダウンロードが完了すると、コンテナーが実行され、Web サーバー上でイメージをホストします。このコンテナーは公式 HTTPd イメージのバリエーションを使用しているので、IPv6 ネットワークでの動作も可能になります。

1.7.12.6.6. IPv6 ネットワークのイメージミラーリングを設定する

イメージミラーリングは、registry.redhat.com や quay.io などの外部レジストリーからイメージを取得し、プライベートレジストリーに保存するプロセスです。

1.7.12.6.6.1. ミラーリングプロセスの完了

注: ミラーリングプロセスは、レジストリーサーバーの実行後に開始してください。

次の手順では、ImageSetConfiguration オブジェクトを使用するバイナリーである、oc-mirror ツールが使用されます。このファイルで、以下の情報を指定できます。

  • ミラーリングする OpenShift Container Platform バージョン。バージョンは quay.io にあります。
  • ミラーリングする追加の Operator。パッケージは個別に選択します。
  • リポジトリーに追加する追加のイメージ。

イメージのミラーリングを設定するには、以下の手順を実行します。

  1. ${HOME}/.docker/config.json ファイルが、ミラーリング元のレジストリーとイメージのプッシュ先のプライベートレジストリーで更新されていることを確認します。

  2. 次の例を使用して、ミラーリングに使用する 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.14
      minVersion: 4.x.y-x86_64
      maxVersion: 4.x.y-x86_64
      type: ocp
    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.14-rc-v3
  - name: registry.redhat.io/openshift4/ose-kube-rbac-proxy:v4.10
  operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.14
    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
    1
    dns.base.domain.name を DNS ベースドメイン名に置き換え、4.x.y を使用したいサポートされている OpenShift Container Platform バージョンに置き換えます。

  3. 次のコマンドを入力して、ミラーリングプロセスを開始します。 

    oc-mirror --source-skip-tls --config imagesetconfig.yaml docker://${REGISTRY}

    ミラーリングプロセスが完了すると、oc-mirror-workspace/results-XXXXXX/ という名前の新しいフォルダーが作成されます。このフォルダーには、ICSP と、ホステッドクラスターに適用するカタログソースが含まれます。

  4. oc adm release mirror コマンドを使用して、OpenShift Container Platform のナイトリーバージョンまたは CI バージョンをミラーリングします。以下のコマンドを入力します。 

    REGISTRY=registry.$(hostname --long):5000

oc adm release mirror \
  --from=registry.ci.openshift.org/ocp/release:4.x.y-x86_64 \
  --to=${REGISTRY}/openshift/release \
  --to-release-image=${REGISTRY}/openshift/release-images:4.x.y-x86_64

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

  5. 非接続ネットワークへのインストール の手順に従って、最新のマルチクラスターエンジン Operator イメージをミラーリングします。
1.7.12.6.6.2. 管理クラスターでのオブジェクトの適用

ミラーリングプロセスが完了したら、管理クラスターに 2 つのオブジェクトを適用する必要があります。

  • イメージコンテンツソースポリシー (ICSP) またはイメージダイジェストミラーセット (IDMS)
  • カタログソース

oc-mirror ツールを使用すると、出力アーティファクトは oc-mirror-workspace/results-XXXXXX/ という名前のフォルダーに保存されます。

ICSP または IDMS は、ノードを再起動せずに、各ノードで kubelet を再起動する MachineConfig 変更を開始します。ノードが READY としてマークされたら、新しく生成されたカタログソースを適用する必要があります。

カタログソースは、カタログイメージのダウンロードや処理を行い、そのイメージに含まれるすべての PackageManifests を取得するなど、openshift-marketplace Operator でアクションを開始します。

  1. 新しいソースを確認するには、新しい CatalogSource をソースとして使用して次のコマンドを実行します。 

    oc get packagemanifest

  2. アーティファクトを適用するには、次の手順を実行します。

    1. 次のコマンドを入力して、ICSP または IDMS アーティファクトを作成します。 

      oc apply -f oc-mirror-workspace/results-XXXXXX/imageContentSourcePolicy.yaml
    2. ノードの準備が完了するまで待ってから、次のコマンドを入力します。 
    oc apply -f catalogSource-XXXXXXXX-index.yaml
1.7.12.6.6.3. 関連情報
1.7.12.6.7. IPv6 ネットワーク用のマルチクラスターエンジン Operator をデプロイする

マルチクラスターエンジン Operator は、プロバイダー間でクラスターをデプロイメントする場合に重要な役割を果たします。Red Hat Advanced Cluster Management をすでにインストールしている場合は、マルチクラスターエンジン Operator は自動的にインストールされるため、インストールする必要はありません。

マルチクラスターエンジン Operator がインストールされていない場合は、次のドキュメントを参照して、前提条件とインストール手順を確認してください。

1.7.12.6.7.1. AgentServiceConfig リソースのデプロイ

AgentServiceConfig カスタムリソースは、マルチクラスターエンジン Operator の一部である Assisted Service アドオンの重要なコンポーネントです。このコンポーネントは、ベアメタルクラスターをデプロイメントします。アドオンが有効な場合に、AgentServiceConfig リソースをデプロイしてアドオンを設定します。

AgentServiceConfig リソースの設定に加えて、マルチクラスターエンジン Operator が非接続環境で適切に機能するように、追加の config map を含める必要があります。

  1. 次の config map を追加してカスタムレジストリーを設定します。これには、デプロイメントをカスタマイズするための非接続環境の情報が含まれています。 

    ---
apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-registries
  namespace: multicluster-engine
  labels:
    app: assisted-service
data:
  ca-bundle.crt: |
    -----BEGIN CERTIFICATE-----
    -----END CERTIFICATE-----
  registries.conf: |
    unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]

    [[registry]]
    prefix = ""
    location = "registry.redhat.io/openshift4"
    mirror-by-digest-only = true

    [[registry.mirror]]
      location = "registry.dns.base.domain.name:5000/openshift4" 1

    [[registry]]
    prefix = ""
    location = "registry.redhat.io/rhacm2"
    mirror-by-digest-only = true
    ...
    ...
    1
    dns.base.domain.name は DNS ベースドメイン名に置き換えます。

    オブジェクトには、以下の 2 つのフィールドが含まれます。

    • カスタム CA: このフィールドには、デプロイメントのさまざまなプロセスに読み込まれる認証局 (CA) が含まれます。
    • レジストリー: Registries.conf フィールドには、元のソースレジストリーではなくミラーレジストリーから使用する必要があるイメージと namespace に関する情報が含まれています。

  2. 次の例に示すように、AssistedServiceConfig オブジェクトを追加して、Assisted Service を設定します。 

    ---
apiVersion: agent-install.openshift.io/v1beta1
kind: AgentServiceConfig
metadata:
  annotations:
    unsupported.agent-install.openshift.io/assisted-service-configmap: assisted-service-config 1
  name: agent
  namespace: multicluster-engine
spec:
  mirrorRegistryRef:
    name: custom-registries 2
  databaseStorage:
    storageClassName: lvms-vg1
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: 10Gi
  filesystemStorage:
    storageClassName: lvms-vg1
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: 20Gi
  osImages: 3
  - cpuArchitecture: x86_64
    openshiftVersion: "4.14"
    rootFSUrl: http://registry.dns.base.domain.name:8080/images/rhcos-414.92.202308281054-0-live-rootfs.x86_64.img 4
    url: http://registry.dns.base.domain.name:8080/images/rhcos-414.92.202308281054-0-live.x86_64.iso
    version: 414.92.202308281054-0
    1
    metadata.annotations["unsupported.agent-install.openshift.io/assisted-service-configmap"] アノテーションは、Operator が動作をカスタマイズするために使用する config map 名を参照します。
    2
    spec.mirrorRegistryRef.name アノテーションは、Assisted Service Operator が使用する非接続のレジストリー情報を含む config map を指します。この config map は、デプロイメントプロセス中にこれらのリソースを追加します。
    3
    spec.osImages フィールドには、この Operator がデプロイできるさまざまなバージョンが含まれています。このフィールドは必須です。この例では、RootFS ファイルと LiveISO ファイルがすでにダウンロードされていることを前提としています。
    4
    rootFSUrl フィールド と url フィールドで、dns.base.domain.name を DNS ベースドメイン名に置き換えます。

  3. すべてのオブジェクトを 1 つのファイルに連結し、管理クラスターに適用し、これらのオブジェクトをデプロイします。起動するには、以下のコマンドを実行します。 

    oc apply -f agentServiceConfig.yaml

    このコマンドは、次の出力例に示すように、2 つの Pod をトリガーします。 

    assisted-image-service-0                               1/1     Running   2             11d 1
assisted-service-668b49548-9m7xw                       2/2     Running   5             11d 2
    1
    assisted-image-service Pod は、デプロイするクラスターごとにカスタマイズされた、Red Hat Enterprise Linux CoreOS (RHCOS) 起動イメージテンプレートを作成します。
    2
    assisted-service は Operator を参照します。
1.7.12.6.8. IPv6 ネットワークの TLS 証明書を設定する

オフライン環境で Hosted Control Plane を設定するプロセスに、いくつかの TLS 証明書が関与します。認証局 (CA) を管理クラスターに追加するには、OpenShift Container Platform コントロールプレーンおよびワーカーノード内の以下のファイルの内容を変更する必要があります。

  • /etc/pki/ca-trust/extracted/pem/
  • /etc/pki/ca-trust/source/anchors
  • /etc/pki/tls/certs/

CA を管理クラスターに追加するには、次の手順を実行します。

  1. OpenShift Container Platform の公式ドキュメントの CA バンドルの更新 の手順を完了します。この方法には、CA を OpenShift Container Platform ノードにデプロイする image-registry-operator の使用が含まれます。

  2. この方法が実際の状況に該当しない場合は、管理クラスター内の openshift-config namespace に user-ca-bundle という名前の config map が含まれているかどうかを確認してください。

    • namespace にその config map が含まれている場合は、次のコマンドを入力します。 

      ## REGISTRY_CERT_PATH=<PATH/TO/YOUR/CERTIFICATE/FILE>
export REGISTRY_CERT_PATH=/opt/registry/certs/domain.crt

oc create configmap user-ca-bundle -n openshift-config --from-file=ca-bundle.crt=${REGISTRY_CERT_PATH}

    • namespace にその config map が含まれていない場合は、以下のコマンドを入力します。 

      ## REGISTRY_CERT_PATH=<PATH/TO/YOUR/CERTIFICATE/FILE>
export REGISTRY_CERT_PATH=/opt/registry/certs/domain.crt
export TMP_FILE=$(mktemp)

oc get cm -n openshift-config user-ca-bundle -ojsonpath='{.data.ca-bundle\.crt}' > ${TMP_FILE}
echo >> ${TMP_FILE}
echo \#registry.$(hostname --long) >> ${TMP_FILE}
cat ${REGISTRY_CERT_PATH} >> ${TMP_FILE}
oc create configmap user-ca-bundle -n openshift-config --from-file=ca-bundle.crt=${TMP_FILE} --dry-run=client -o yaml | kubectl apply -f -
1.7.12.6.9. IPv6 ネットワークのホステッドクラスターをデプロイする

ホステッドクラスターは、コントロールプレーンと API エンドポイントが管理クラスターでホストされている OpenShift Container Platform クラスターです。ホステッドクラスターには、コントロールプレーンとそれに対応するデータプレーンが含まれます。

Red Hat Advanced Cluster Management のコンソールを使用してホステッドクラスターを作成できますが、次の手順ではマニフェストを使用するため、関連するアーティファクトをより柔軟に変更できます。

1.7.12.6.9.1. ホステッドクラスターオブジェクトのデプロイ

この手順では、次の値が使用されます。

  • HostedCluster name: hosted-ipv6
  • HostedCluster namespace: clusters
  • Disconnected: true
  • Network stack: IPv6

通常、HyperShift Operator は HostedControlPlane namespace を作成します。ただし、この場合は、HyperShift Operator が HostedCluster オブジェクトの調整を開始する前に、すべてのオブジェクトを含める必要があります。その後、Operator が調整プロセスを開始すると、所定の場所にあるすべてのオブジェクトを見つけることができます。

  1. namespace に関する次の情報を含めて、YAML ファイルを作成します。 

    ---
apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: null
  name: clusters-hosted-ipv6
spec: {}
status: {}
---
apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: null
  name: clusters
spec: {}
status: {}

  2. config map とシークレットに関する次の情報を含む YAML ファイルを作成し、HostedCluster デプロイメントに追加します。 

    ---
apiVersion: v1
data:
  ca-bundle.crt: |
    -----BEGIN CERTIFICATE-----
    -----END CERTIFICATE-----
kind: ConfigMap
metadata:
  name: user-ca-bundle
  namespace: clusters
---
apiVersion: v1
data:
  .dockerconfigjson: xxxxxxxxx
kind: Secret
metadata:
  creationTimestamp: null
  name: hosted-ipv6-pull-secret
  namespace: clusters
---
apiVersion: v1
kind: Secret
metadata:
  name: sshkey-cluster-hosted-ipv6
  namespace: clusters
stringData:
  id_rsa.pub: ssh-rsa xxxxxxxxx
---
apiVersion: v1
data:
  key: nTPtVBEt03owkrKhIdmSW8jrWRxU57KO/fnZa8oaG0Y=
kind: Secret
metadata:
  creationTimestamp: null
  name: hosted-ipv6-etcd-encryption-key
  namespace: clusters
type: Opaque

  3. RBAC ロールを含む YAML ファイルを作成し、Assisted Service エージェントが Hosted Control Plane と同じ HostedControlPlane namespace に配置し、引き続きクラスター API で管理されるようにします。 

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  creationTimestamp: null
  name: capi-provider-role
  namespace: clusters-hosted-ipv6
rules:
- apiGroups:
  - agent-install.openshift.io
  resources:
  - agents
  verbs:
  - '*'

  4. HostedCluster オブジェクトに関する情報を含む YAML ファイルを作成し、必要に応じて値を置き換えます。 

    apiVersion: hypershift.openshift.io/v1beta1
kind: HostedCluster
metadata:
  name: hosted-ipv6
  namespace: clusters
  annotations:
    hypershift.openshift.io/control-plane-operator-image: registry.ocp-edge-cluster-0.qe.lab.redhat.com:5005/openshift/release@sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8
spec:
  additionalTrustBundle:
    name: "user-ca-bundle"
  olmCatalogPlacement: guest
  imageContentSources: 1
  - source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
    mirrors:
    - registry.dns.base.domain.name:5000/openshift/release
  - source: quay.io/openshift-release-dev/ocp-release
    mirrors:
    - registry.dns.base.domain.name:5000/openshift/release-images
  - mirrors:
  ...
  ...
  autoscaling: {}
  controllerAvailabilityPolicy: SingleReplica
  dns:
    baseDomain: dns.base.domain.name
  etcd:
    managed:
      storage:
        persistentVolume:
          size: 8Gi
        restoreSnapshotURL: null
        type: PersistentVolume
    managementType: Managed
  fips: false
  networking:
    clusterNetwork:
    - cidr: 10.132.0.0/14
    networkType: OVNKubernetes
    serviceNetwork:
    - cidr: 172.31.0.0/16
  platform:
    agent:
      agentNamespace: clusters-hosted-ipv6
    type: Agent
  pullSecret:
    name: hosted-ipv6-pull-secret
  release:
    image: registry.dns.base.domain.name:5000/openshift/release-images:4.x.y-x86_64
  secretEncryption:
    aescbc:
      activeKey:
        name: hosted-ipv6-etcd-encryption-key
    type: aescbc
  services:
  - service: APIServer
    servicePublishingStrategy:
      nodePort:
        address: api.hosted-ipv6.dns.base.domain.name
      type: NodePort
  - service: OAuthServer
    servicePublishingStrategy:
      nodePort:
        address: api.hosted-ipv6.dns.base.domain.name
      type: NodePort
  - service: OIDC
    servicePublishingStrategy:
      nodePort:
        address: api.hosted-ipv6.dns.base.domain.name
      type: NodePort
  - service: Konnectivity
    servicePublishingStrategy:
      nodePort:
        address: api.hosted-ipv6.dns.base.domain.name
      type: NodePort
  - service: Ignition
    servicePublishingStrategy:
      nodePort:
        address: api.hosted-ipv6.dns.base.domain.name
      type: NodePort
  sshKey:
    name: sshkey-cluster-hosted-ipv6
status:
  controlPlaneEndpoint:
    host: ""
    port: 0

    ここで、dns.base.domain.name は DNS ベースドメイン名であり、4.x.y は使用するサポートされている OpenShift Container Platform のバージョンです。

    1
    imageContentSources セクションには、ホステッドクラスター内のユーザーワークロードのミラー参照が含まれます。

  5. OpenShift Container Platform リリースの HyperShift Operator リリースを指すアノテーションを HostedCluster オブジェクトに追加します。

    1. 次のコマンドを入力して、イメージペイロードを取得します。 

      oc adm release info registry.dns.base.domain.name:5000/openshift-release-dev/ocp-release:4.x.y-x86_64 | grep hypershift

      ここで、dns.base.domain.name は DNS ベースドメイン名であり、4.x.y は使用するサポートされている OpenShift Container Platform のバージョンです。

    2. 以下の出力を参照してください。 

      hypershift                                     sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8

    3. OpenShift Container Platform Images namespace を使用して、次のコマンドを入力してダイジェストを確認します。 

      podman pull registry.dns.base.domain.name:5000/openshift-release-dev/ocp-v4.0-art-dev@sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8

      dns.base.domain.name は DNS ベースドメイン名です。

    4. 以下の出力を参照してください。 

      podman pull registry.dns.base.domain.name:5000/openshift/release@sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8
Trying to pull registry.dns.base.domain.name:5000/openshift/release@sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8...
Getting image source signatures
Copying blob d8190195889e skipped: already exists
Copying blob c71d2589fba7 skipped: already exists
Copying blob d4dc6e74b6ce skipped: already exists
Copying blob 97da74cc6d8f skipped: already exists
Copying blob b70007a560c9 done
Copying config 3a62961e6e done
Writing manifest to image destination
Storing signatures
3a62961e6ed6edab46d5ec8429ff1f41d6bb68de51271f037c6cb8941a007fde

    注: HostedCluster オブジェクトに設定されるリリースイメージでは、タグではなくダイジェストを使用する必要があります (例: quay.io/openshift-release-dev/ocp-release@sha256:e3ba11bd1e5e8ea5a0b36a75791c90f29afb0fdbe4125be4e48f69c76a5c47a0)。

  6. YAML ファイルで定義したすべてのオブジェクトを 1 つのファイルに連結し、管理クラスターに対して適用して作成します。起動するには、以下のコマンドを実行します。 

    oc apply -f 01-4.14-hosted_cluster-nodeport.yaml

  7. Hosted Control Plane の出力を参照してください。 

    NAME                                                  READY   STATUS    RESTARTS   AGE
capi-provider-5b57dbd6d5-pxlqc                        1/1     Running   0          3m57s
catalog-operator-9694884dd-m7zzv                      2/2     Running   0          93s
cluster-api-f98b9467c-9hfrq                           1/1     Running   0          3m57s
cluster-autoscaler-d7f95dd5-d8m5d                     1/1     Running   0          93s
cluster-image-registry-operator-5ff5944b4b-648ht      1/2     Running   0          93s
cluster-network-operator-77b896ddc-wpkq8              1/1     Running   0          94s
cluster-node-tuning-operator-84956cd484-4hfgf         1/1     Running   0          94s
cluster-policy-controller-5fd8595d97-rhbwf            1/1     Running   0          95s
cluster-storage-operator-54dcf584b5-xrnts             1/1     Running   0          93s
cluster-version-operator-9c554b999-l22s7              1/1     Running   0          95s
control-plane-operator-6fdc9c569-t7hr4                1/1     Running   0          3m57s
csi-snapshot-controller-785c6dc77c-8ljmr              1/1     Running   0          77s
csi-snapshot-controller-operator-7c6674bc5b-d9dtp     1/1     Running   0          93s
csi-snapshot-webhook-5b8584875f-2492j                 1/1     Running   0          77s
dns-operator-6874b577f-9tc6b                          1/1     Running   0          94s
etcd-0                                                3/3     Running   0          3m39s
hosted-cluster-config-operator-f5cf5c464-4nmbh        1/1     Running   0          93s
ignition-server-6b689748fc-zdqzk                      1/1     Running   0          95s
ignition-server-proxy-54d4bb9b9b-6zkg7                1/1     Running   0          95s
ingress-operator-6548dc758b-f9gtg                     1/2     Running   0          94s
konnectivity-agent-7767cdc6f5-tw782                   1/1     Running   0          95s
kube-apiserver-7b5799b6c8-9f5bp                       4/4     Running   0          3m7s
kube-controller-manager-5465bc4dd6-zpdlk              1/1     Running   0          44s
kube-scheduler-5dd5f78b94-bbbck                       1/1     Running   0          2m36s
machine-approver-846c69f56-jxvfr                      1/1     Running   0          92s
oauth-openshift-79c7bf44bf-j975g                      2/2     Running   0          62s
olm-operator-767f9584c-4lcl2                          2/2     Running   0          93s
openshift-apiserver-5d469778c6-pl8tj                  3/3     Running   0          2m36s
openshift-controller-manager-6475fdff58-hl4f7         1/1     Running   0          95s
openshift-oauth-apiserver-dbbc5cc5f-98574             2/2     Running   0          95s
openshift-route-controller-manager-5f6997b48f-s9vdc   1/1     Running   0          95s
packageserver-67c87d4d4f-kl7qh                        2/2     Running   0          93s

  8. ホステッドクラスターの出力を確認します。 

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

次に、NodePool オブジェクトを作成します。

1.7.12.6.9.2. ホステッドクラスターの NodePool オブジェクトの作成

NodePool は、ホステッドクラスターに関連付けられたスケーラブルなワーカーノードのセットです。NodePool マシンアーキテクチャーは特定のプール内で一貫性を保ち、コントロールプレーンのマシンアーキテクチャーから独立しています。

  1. NodePool オブジェクトに関する次の情報を含む YAML ファイルを作成し、必要に応じて値を置き換えます。 

    apiVersion: hypershift.openshift.io/v1beta1
kind: NodePool
metadata:
  creationTimestamp: null
  name: hosted-ipv6
  namespace: clusters
spec:
  arch: amd64
  clusterName: hosted-ipv6
  management:
    autoRepair: false 1
    upgradeType: InPlace 2
  nodeDrainTimeout: 0s
  platform:
    type: Agent
  release:
    image: registry.dns.base.domain.name:5000/openshift/release-images:4.x.y-x86_64 3
  replicas: 0
status:
  replicas: 0 4
    1
    ノードが削除された場合、ノードは再作成されないため、autoRepair フィールドは false に設定されます。
    2
    upgradeType は InPlace に設定されます。これは、アップグレード中に同じベアメタルノードが再利用されることを示します。
    3
    この NodePool に含まれるすべてのノードは、OpenShift Container Platform バージョン 4.x.y-x86_64 に基づいています。dns.base.domain.name を DNS ベースドメイン名に置き換え、4.x.y を使用したいサポートされている OpenShift Container Platform バージョンに置き換えます。
    4
    replicas の値は 0 に設定されているため、必要に応じてスケールを変更できます。すべての手順が完了するまで、NodePool レプリカを 0 に保つことが重要です。

  2. 次のコマンドを入力して、NodePool オブジェクトを作成します。 

    oc apply -f 02-nodepool.yaml

  3. 出力を参照してください。 

    NAMESPACE   NAME          CLUSTER   DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION                              UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
clusters    hosted-ipv6   hosted    0                               False         False        4.x.y-x86_64

次に、InfraEnv リソースを作成します。

1.7.12.6.9.3. ホステッドクラスターの InfraEnv リソースの作成

InfraEnv リソースは、pullSecretRef や sshAuthorizedKey などの重要な詳細を含む Assisted Service オブジェクトです。これらの詳細は、ホステッドクラスター用にカスタマイズされた Red Hat Enterprise Linux CoreOS (RHCOS) ブートイメージを作成するために使用されます。

  1. InfraEnv リソースに関する次の情報を含めて YAML ファイルを作成し、必要に応じて値を置き換えます。 

    ---
apiVersion: agent-install.openshift.io/v1beta1
kind: InfraEnv
metadata:
  name: hosted-ipv6
  namespace: clusters-hosted-ipv6
spec:
  pullSecretRef: 1
    name: pull-secret
  sshAuthorizedKey: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDk7ICaUE+/k4zTpxLk4+xFdHi4ZuDi5qjeF52afsNkw0w/glILHhwpL5gnp5WkRuL8GwJuZ1VqLC9EKrdmegn4MrmUlq7WTsP0VFOZFBfq2XRUxo1wrRdor2z0Bbh93ytR+ZsDbbLlGngXaMa0Vbt+z74FqlcajbHTZ6zBmTpBVq5RHtDPgKITdpE1fongp7+ZXQNBlkaavaqv8bnyrP4BWahLP4iO9/xJF9lQYboYwEEDzmnKLMW1VtCE6nJzEgWCufACTbxpNS7GvKtoHT/OVzw8ArEXhZXQUS1UY8zKsX2iXwmyhw5Sj6YboA8WICs4z+TrFP89LmxXY0j6536TQFyRz1iB4WWvCbH5n6W+ABV2e8ssJB1AmEy8QYNwpJQJNpSxzoKBjI73XxvPYYC/IjPFMySwZqrSZCkJYqQ023ySkaQxWZT7in4KeMu7eS2tC+Kn4deJ7KwwUycx8n6RHMeD8Qg9flTHCv3gmab8JKZJqN3hW1D378JuvmIX4V0= 2
    1
    pullSecretRef は、プルシークレットが使用される InfraEnv と同じ namespace 内の config map を参照します。
    2
    sshAuthorizedKey は、ブートイメージに配置される SSH 公開鍵を表します。SSH 鍵を使用すると、core ユーザーとしてワーカーノードにアクセスできます。

  2. 次のコマンドを入力して、InfraEnv リソースを作成します。 

    oc apply -f 03-infraenv.yaml

  3. 以下の出力を参照してください。 

    NAMESPACE              NAME     ISO CREATED AT
clusters-hosted-ipv6   hosted   2023-09-11T15:14:10Z

次に、ワーカーノードを作成します。

1.7.12.6.9.4. ホステッドクラスター用のワーカーノードの作成

ベアメタルプラットフォームで作業している場合、BareMetalHost の詳細が正しく設定されていることを確認するためにワーカーノードを作成することが重要です。

仮想マシンを使用している場合は、次の手順を実行して、Metal3 Operator が使用する空のワーカーノードを作成できます。これには、kcli ツールを使用します。

  1. ワーカーノードを作成するのが初めてではない場合は、まず以前の設定を削除する必要があります。これには、次のコマンドを入力してプランを削除します。 

    kcli delete plan hosted-ipv6
    1. プランを削除するかどうかを確認するプロンプトが表示されたら、y と入力します。
    2. プランが削除されたことを示すメッセージが表示されることを確認します。

  2. 次のコマンドを入力して仮想マシンを作成します。 

    kcli create vm -P start=False -P uefi_legacy=true -P plan=hosted-ipv6 -P memory=8192 -P numcpus=16 -P disks=[200,200] -P nets=["{\"name\": \"ipv6\", \"mac\": \"aa:aa:aa:aa:02:11\"}"] -P uuid=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0211 -P name=hosted-ipv6-worker0
    kcli create vm -P start=False -P uefi_legacy=true -P plan=hosted-ipv6 -P memory=8192 -P numcpus=16 -P disks=[200,200] -P nets=["{\"name\": \"ipv6\", \"mac\": \"aa:aa:aa:aa:02:12\"}"] -P uuid=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0212 -P name=hosted-ipv6-worker1
    kcli create vm -P start=False -P uefi_legacy=true -P plan=hosted-ipv6 -P memory=8192 -P numcpus=16 -P disks=[200,200] -P nets=["{\"name\": \"ipv6\", \"mac\": \"aa:aa:aa:aa:02:13\"}"] -P uuid=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0213 -P name=hosted-ipv6-worker2
    systemctl restart ksushy

    ここでは、以下のようになります。

    • start=False は、仮想マシン (VM) が作成時に自動的に起動しないことを意味します。
    • uefi_legacy=true は、以前の UEFI 実装との互換性を確保するために UEFI レガシーブートを使用することを意味します。
    • plan=hosted-dual は、マシンのグループをクラスターとして識別するプラン名を示します。
    • memory=8192 および numcpus=16 は、RAM や CPU などの仮想マシンのリソースを指定するパラメーターです。
    • disks=[200,200] は、VM 内に 2 つのシンプロビジョニングディスクを作成していることを示します。
    • nets=[{"name": "dual", "mac": "aa:aa:aa:aa:02:13"}] は、接続するネットワーク名やプライマリーインターフェイスの MAC アドレスなど、ネットワークの詳細です。
    • restart ksushy は、ksushy ツールを再起動して、追加した VM をツールが確実に検出できるようにします。

  3. 結果の出力を確認します。 

    +---------------------+--------+-------------------+----------------------------------------------------+-------------+---------+
|         Name        | Status |         Ip        |                       Source                       |     Plan    | Profile |
+---------------------+--------+-------------------+----------------------------------------------------+-------------+---------+
|    hosted-worker0   |  down  |                   |                                                    | hosted-ipv6 |  kvirt  |
|    hosted-worker1   |  down  |                   |                                                    | hosted-ipv6 |  kvirt  |
|    hosted-worker2   |  down  |                   |                                                    | hosted-ipv6 |  kvirt  |
+---------------------+--------+-------------------+----------------------------------------------------+-------------+---------+

次に、ホステッドクラスターのベアメタルホストを作成します。

1.7.12.6.9.5. ホステッドクラスターのベアメタルホスト作成

ベアメタルホスト は、物理的な詳細と論理詳細を含む openshift-machine-api オブジェクトで、Metal3 Operator によって識別できるようになっています。これらの詳細は、agents と呼ばれる他の Assisted Service オブジェクトに関連付けられています。

重要: ベアメタルホストと移行先ノードを作成する前に、仮想マシンを作成する必要があります。

ベアメタルホストを作成するには、以下の手順を実行します。

  1. 次の情報を使用して YAML ファイルを作成します。

    注記: ベアメタルホストの認証情報を保持するシークレットが 1 つ以上あるため、ワーカーノードごとに少なくとも 2 つのオブジェクトを作成する必要があります。 

    ---
apiVersion: v1
kind: Secret
metadata:
  name: hosted-ipv6-worker0-bmc-secret
  namespace: clusters-hosted-ipv6
data:
  password: YWRtaW4=
  username: YWRtaW4=
type: Opaque
---
apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: hosted-ipv6-worker0
  namespace: clusters-hosted-ipv6
  labels:
    infraenvs.agent-install.openshift.io: hosted-ipv6 1
  annotations:
    inspect.metal3.io: disabled
    bmac.agent-install.openshift.io/hostname: hosted-ipv6-worker0 2
spec:
  automatedCleaningMode: disabled 3
  bmc:
    disableCertificateVerification: true 4
    address: redfish-virtualmedia://[192.168.125.1]:9000/redfish/v1/Systems/local/hosted-ipv6-worker0 5
    credentialsName: hosted-ipv6-worker0-bmc-secret 6
  bootMACAddress: aa:aa:aa:aa:03:11 7
  online: true 8
    1
    infraenvs.agent-install.openshift.io は、Assisted Installer オブジェクトと BareMetalHost オブジェクト間のリンクとして機能します。
    2
    bmac.agent-install.openshift.io/hostname は、デプロイメント中に採用されるノード名を表します。
    3
    automatedCleaningMode は、ノードが Metal3 Operator によって消去されるのを防ぎます。
    4
    disableCertificateVerification は true に設定され、クライアントから証明書の検証がバイパスされます。
    5
    address は、ワーカーノードのベースボード管理コントローラー (BMC) アドレスを示します。
    6
    credentialsName は、ユーザーとパスワードの認証情報が保存されるシークレットを指します。
    7
    bootMACAddress は、ノードの起動元のインターフェイス MAC アドレスを示します。
    8
    online は、BareMetalHost オブジェクトが作成された後のノードの状態を定義します。

  2. 次のコマンドを入力して、BareMetalHost オブジェクトをデプロイします。 

    oc apply -f 04-bmh.yaml

    プロセス中に、次の出力が確認できます。

    • この出力は、プロセスがノードに到達しようとしていることを示しています。 

      NAMESPACE         NAME             STATE         CONSUMER   ONLINE   ERROR   AGE
clusters-hosted   hosted-worker0   registering              true             2s
clusters-hosted   hosted-worker1   registering              true             2s
clusters-hosted   hosted-worker2   registering              true             2s

    • この出力は、ノードが起動していることを示しています。 

      NAMESPACE         NAME             STATE          CONSUMER   ONLINE   ERROR   AGE
clusters-hosted   hosted-worker0   provisioning              true             16s
clusters-hosted   hosted-worker1   provisioning              true             16s
clusters-hosted   hosted-worker2   provisioning              true             16s
    • この出力は、ノードが正常に起動したことを示しています。 
    NAMESPACE         NAME             STATE         CONSUMER   ONLINE   ERROR   AGE
clusters-hosted   hosted-worker0   provisioned              true             67s
clusters-hosted   hosted-worker1   provisioned              true             67s
clusters-hosted   hosted-worker2   provisioned              true             67s

  3. ノードが起動したら、次の例に示すように、namespace のエージェントに注目してください。 

    NAMESPACE         NAME                                   CLUSTER   APPROVED   ROLE          STAGE
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0411             true       auto-assign
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0412             true       auto-assign
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0413             true       auto-assign

    エージェントは、インストールに使用できるノードを表します。ホステッドクラスターにノードを割り当てるには、ノードプールをスケールアップします。

1.7.12.6.9.6. ノードプールのスケールアップ

ベアメタルホストを作成すると、そのステータスが Registering Provisioning、Provisioned に変わります。ノードは、エージェントの LiveISO と、agent という名前のデフォルトの Pod で始まります。このエージェントは、Assisted Service Operator から OpenShift Container Platform ペイロードをインストールする指示を受け取ります。

  1. ノードプールをスケールアップするには、次のコマンドを入力します。 

    oc -n clusters scale nodepool hosted-ipv6 --replicas 3

  2. スケーリングプロセスが完了すると、エージェントがホステッドクラスターに割り当てられていることがわかります。 

    NAMESPACE         NAME                                   CLUSTER   APPROVED   ROLE          STAGE
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0211   hosted    true       auto-assign
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0212   hosted    true       auto-assign
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0213   hosted    true       auto-assign

  3. また、ノードプールレプリカが設定されていることにも注意してください。 

    NAMESPACE   NAME     CLUSTER   DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION             UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
clusters    hosted   hosted    3                               False         False        4.x.y-x86_64                                           Minimum availability requires 3 replicas, current 0 available
  4. ノードがクラスターに参加するまで待ちます。プロセス中に、エージェントはステージとステータスに関する最新情報を提供します。

次に、ホステッドクラスターのデプロイメントを監視します。

1.7.12.6.10. IPv6 ネットワークのホステッドクラスターのデプロイメントを完了する

ホステッドクラスターのデプロイメントは、コントロールプレーンとデータプレーンの 2 つの観点から監視できます。

1.7.12.6.10.1. コントロールプレーンの監視

ホステッドクラスターのデプロイメント中に、次のコマンドを入力してコントロールプレーンを監視できます。 

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;"

これらのコマンドは、次のアーティファクトに関する情報を提供します。

  • HyperShift Operator
  • HostedControlPlane Pod
  • ベアメタルホスト
  • エージェント
  • InfraEnv リソース
  • HostedCluster および NodePool リソース
1.7.12.6.10.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"

これらのコマンドは、次のアーティファクトに関する情報を提供します。

  • クラスターのバージョン
  • ノード (特にノードがクラスターに参加したかどうかについて)
  • クラスター Operator

1.7.12.7. デュアルスタックネットワーク上での Hosted Control Plane の設定 (テクノロジープレビュー)

Hosted Control Plane のコンテキストでは、非接続環境は、インターネットに接続されておらず、Hosted Control Plane をベースとして使用する OpenShift Container Platform クラスターです。リモートレジストリーは IPv6 では機能しないため、非接続環境のデュアルスタックネットワークでのみ Hosted Control Plane を設定できます。

デュアルスタックネットワークで Hosted Control Plane を設定するには、次の手順を確認します。

  1. デュアルスタックネットワーク用のハイパーバイザーの設定
  2. デュアルスタックネットワーク用の DNS の設定
  3. デュアルスタックネットワーク用のレジストリーのデプロイ
  4. デュアルスタックネットワークの管理クラスターの設定
  5. デュアルスタックネットワーク用の Web サーバーの設定
  6. デュアルスタックネットワークのイメージミラーリングの設定
  7. デュアルスタックネットワーク用の multicluster engine Operator のデプロイ
  8. デュアルスタックネットワークの TLS 証明書の設定
  9. デュアルスタックネットワーク用のホステッドクラスターのデプロイ
  10. デュアルスタックネットワークのデプロイメントの終了
1.7.12.7.1. デュアルスタックネットワーク用のハイパーバイザーの設定

以下の情報は、仮想マシン環境にのみ適用されます。

1.7.12.7.1.1. 仮想 OpenShift Container Platform クラスターのパッケージへのアクセスおよびデプロイ

  1. 仮想 OpenShift Container Platform 管理クラスターをデプロイするには、以下のコマンドを入力して必要なパッケージにアクセスします。 

    sudo dnf install dnsmasq radvd vim golang podman bind-utils net-tools httpd-tools tree htop strace tmux -y

  2. 次のコマンドを入力して、Podman サービスを有効にして起動します。 

    systemctl enable --now podman

  3. kcli を使用して OpenShift Container Platform 管理クラスターおよびその他の仮想コンポーネントをデプロイするには、以下のコマンドを入力してハイパーバイザーをインストールおよび設定します。 

    sudo yum -y install libvirt libvirt-daemon-driver-qemu qemu-kvm
    sudo usermod -aG qemu,libvirt $(id -un)
    sudo newgrp libvirt
    sudo systemctl enable --now libvirtd
    sudo dnf -y copr enable karmab/kcli
    sudo dnf -y install kcli
    sudo kcli create pool -p /var/lib/libvirt/images default
    kcli create host kvm -H 127.0.0.1 local
    sudo setfacl -m u:$(id -un):rwx /var/lib/libvirt/images
    kcli create network  -c 192.168.122.0/24 default
1.7.12.7.1.2. ネットワークマネージャーディスパッチャーの有効化

  1. ネットワークマネージャーのディスパッチャーを有効にして、仮想マシンが必要なドメイン、ルート、およびレジストリーを解決できるようにします。ネットワークマネージャーディスパッチャーを有効にするには、/etc/NetworkManager/dispatcher.d/ ディレクトリーに次の内容を含む forcedns という名前のスクリプトを作成し、環境に合わせて必要に応じて値を置き換えます。 

    #!/bin/bash

export IP="192.168.126.1" 1
export BASE_RESOLV_CONF="/run/NetworkManager/resolv.conf"

if ! [[ `grep -q "$IP" /etc/resolv.conf` ]]; then
export TMP_FILE=$(mktemp /etc/forcedns_resolv.conf.XXXXXX)
cp $BASE_RESOLV_CONF $TMP_FILE
chmod --reference=$BASE_RESOLV_CONF $TMP_FILE
sed -i -e "s/dns.base.domain.name//" -e "s/search /& dns.base.domain.name /" -e "0,/nameserver/s/nameserver/& $IP\n&/" $TMP_FILE 2
mv $TMP_FILE /etc/resolv.conf
fi
echo "ok"
    1
    OpenShift Container Platform 管理クラスターをホストするハイパーバイザーインターフェイスの IP アドレスを指すように IP 変数を変更します。
    2
    dns.base.domain.name は DNS ベースドメイン名に置き換えます。

  2. ファイルを作成したら、次のコマンドを入力してパーミッションを追加します。 

    chmod 755 /etc/NetworkManager/dispatcher.d/forcedns
  3. スクリプトを実行し、出力が ok を返すことを確認します。
1.7.12.7.1.3. BMC アクセスの設定

  1. 仮想マシンのベースボード管理コントローラー (BMC) をシミュレートするように ksushy を設定します。次のコマンドを入力します。 

    sudo dnf install python3-pyOpenSSL.noarch python3-cherrypy -y
    kcli create sushy-service --ssl --ipv6 --port 9000
    sudo systemctl daemon-reload
    systemctl enable --now ksushy

  2. 次のコマンドを入力して、サービスが正しく機能しているかどうかをテストします。 

    systemctl status ksushy
1.7.12.7.1.4. 接続を許可するためのハイパーバイザーシステムの設定

開発環境で作業している場合は、環境内の各種仮想ネットワークを介したさまざまなタイプの接続を許可するようにハイパーバイザーシステムを設定します。

注: 実稼働環境で作業している場合は、安全な環境を維持するために、firewalld サービスの適切なルールを確立し、SELinux ポリシーを設定する必要があります。

  • SELinux の場合は、次のコマンドを入力します。 

    sed -i s/^SELINUX=.*$/SELINUX=permissive/ /etc/selinux/config; setenforce 0

  • firewalld の場合は、次のコマンドを入力します。 

    systemctl disable --now firewalld

  • libvirtd の場合は、以下のコマンドを入力します。 

    systemctl restart libvirtd
    systemctl enable --now libvirtd

次に、環境に合わせて DNS を設定します。

1.7.12.7.1.5. 関連情報
1.7.12.7.2. デュアルスタックネットワーク用の DNS の設定

DNS の設定は、仮想環境とベアメタル環境の両方で、オフライン環境とオンライン環境の両方で必須です。仮想環境とベアメタル環境の主な違いは、リソースを設定する場所にあります。仮想以外の環境では、dnsmasq のような軽量のソリューションではなく、Bind のようなソリューションを使用してください。

次にレジストリーをデプロイします。

1.7.12.7.3. デュアルスタックネットワーク用のレジストリーのデプロイ

開発環境の場合は、Podman コンテナーを使用して、小規模な自己ホスト型レジストリーをデプロイします。実稼働環境では、Red Hat Quay、Nexus、Artifactory などのエンタープライズでホストされるレジストリーをデプロイします。

Podman を使用して小規模なレジストリーをデプロイするには、以下の手順を実行します。

  1. 特権ユーザーとして ${HOME} ディレクトリーにアクセスし、次のスクリプトを作成します。 

    #!/usr/bin/env bash

set -euo pipefail

PRIMARY_NIC=$(ls -1 /sys/class/net | grep -v podman | head -1)
export PATH=/root/bin:$PATH
export PULL_SECRET="/root/baremetal/hub/openshift_pull.json" 1

if [[ ! -f $PULL_SECRET ]];then
  echo "Pull Secret not found, exiting..."
  exit 1
fi

dnf -y install podman httpd httpd-tools jq skopeo libseccomp-devel
export IP=$(ip -o addr show $PRIMARY_NIC | head -1 | awk '{print $4}' | cut -d'/' -f1)
REGISTRY_NAME=registry.$(hostname --long)
REGISTRY_USER=dummy
REGISTRY_PASSWORD=dummy
KEY=$(echo -n $REGISTRY_USER:$REGISTRY_PASSWORD | base64)
echo "{\"auths\": {\"$REGISTRY_NAME:5000\": {\"auth\": \"$KEY\", \"email\": \"sample-email@domain.ltd\"}}}" > /root/disconnected_pull.json
mv ${PULL_SECRET} /root/openshift_pull.json.old
jq ".auths += {\"$REGISTRY_NAME:5000\": {\"auth\": \"$KEY\",\"email\": \"sample-email@domain.ltd\"}}" < /root/openshift_pull.json.old > $PULL_SECRET
mkdir -p /opt/registry/{auth,certs,data,conf}
cat <<EOF > /opt/registry/conf/config.yml
version: 0.1
log:
  fields:
    service: registry
storage:
  cache:
    blobdescriptor: inmemory
  filesystem:
    rootdirectory: /var/lib/registry
  delete:
    enabled: true
http:
  addr: :5000
  headers:
    X-Content-Type-Options: [nosniff]
health:
  storagedriver:
    enabled: true
    interval: 10s
    threshold: 3
compatibility:
  schema1:
    enabled: true
EOF
openssl req -newkey rsa:4096 -nodes -sha256 -keyout /opt/registry/certs/domain.key -x509 -days 3650 -out /opt/registry/certs/domain.crt -subj "/C=US/ST=Madrid/L=San Bernardo/O=Karmalabs/OU=Guitar/CN=$REGISTRY_NAME" -addext "subjectAltName=DNS:$REGISTRY_NAME"
cp /opt/registry/certs/domain.crt /etc/pki/ca-trust/source/anchors/
update-ca-trust extract
htpasswd -bBc /opt/registry/auth/htpasswd $REGISTRY_USER $REGISTRY_PASSWORD
podman create --name registry --net host --security-opt label=disable --replace -v /opt/registry/data:/var/lib/registry:z -v /opt/registry/auth:/auth:z -v /opt/registry/conf/config.yml:/etc/docker/registry/config.yml -e "REGISTRY_AUTH=htpasswd" -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry" -e "REGISTRY_HTTP_SECRET=ALongRandomSecretForRegistry" -e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd -v /opt/registry/certs:/certs:z -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt -e REGISTRY_HTTP_TLS_KEY=/certs/domain.key docker.io/library/registry:latest
[ "$?" == "0" ] || !!
systemctl enable --now registry
    1
    PULL_SECRET の場所は、設定に適した場所に置き換えます。

  2. スクリプトファイル registry.sh という名前を指定して保存します。スクリプトを実行すると、以下の情報がプルされます。

    • ハイパーバイザーのホスト名に基づくレジストリー名
    • 必要な認証情報およびユーザーアクセスの詳細

  3. 次のように実行フラグを追加して、パーミッションを調整します。 

    chmod u+x ${HOME}/registry.sh

  4. パラメーターを指定せずにスクリプトを実行するには、以下のコマンドを入力します。 

    ${HOME}/registry.sh

    このスクリプトはサーバーを起動します。

  5. このスクリプトは、管理目的で systemd サービスを使用します。スクリプトを管理する必要がある場合は、以下のコマンドを使用できます。 

    systemctl status
    systemctl start
    systemctl stop

レジストリーのルートフォルダーは /opt/registry ディレクトリー内にあり、次のサブディレクトリーが含まれています。

  • certs には TLS 証明書が含まれます。
  • auth には認証情報が含まれます。
  • data にはレジストリーイメージが含まれます。
  • conf にはレジストリー設定が含まれています。
1.7.12.7.4. デュアルスタックネットワークの管理クラスターの設定

OpenShift Container Platform 管理クラスターを設定するには、dev-scripts を使用できます。または、仮想マシンをベースにしている場合は、kcli ツールを使用できます。以下は、kcli ツールに固有のものです。

  1. ハイパーバイザーで使用するために適切なネットワークの準備が完了していることを確認します。ネットワークは、管理クラスターとホステッドクラスターの両方をホストします。以下の kcli コマンドを入力します。 

    kcli create network -c 192.168.126.0/24 -P dhcp=false -P dns=false -d 2620:52:0:1306::0/64 --domain dns.base.domain.name --nodhcp dual

    ここでは、以下のようになります。

    • -c は、ネットワークの CIDR を指定します。
    • -p dhcp=false は、設定した dnsmasq によって処理される DHCP を無効にするようにネットワークを設定します。
    • -P dns=false は、 DNS を無効にするようにネットワークを設定します。これも、設定した dnsmasq によって処理されます。
    • --domain は、検索するドメインを設定します。
    • dns.base.domain.name は DNS ベースドメイン名です。
    • dual は、作成するネットワークの名前です。

  2. ネットワークを作成したら、以下の出力を確認します。 

    [root@hypershiftbm ~]# kcli list network
Listing Networks...
+---------+--------+---------------------+-------+------------------+------+
| Network |  Type  |         Cidr        |  Dhcp |      Domain      | Mode |
+---------+--------+---------------------+-------+------------------+------+
| default | routed |   192.168.122.0/24  |  True |     default      | nat  |
| ipv4    | routed | 2620:52:0:1306::/64 | False | dns.base.domain.name | nat  |
| ipv4    | routed |   192.168.125.0/24  | False | dns.base.domain.name | nat  |
| ipv6    | routed | 2620:52:0:1305::/64 | False | dns.base.domain.name | nat  |
+---------+--------+---------------------+-------+------------------+------+
    [root@hypershiftbm ~]# kcli info network ipv6
Providing information about network ipv6...
cidr: 2620:52:0:1306::/64
dhcp: false
domain: dns.base.domain.name
mode: nat
plan: kvirt
type: routed

  3. OpenShift Container Platform 管理クラスターをデプロイできるように、プルシークレットと kcli プランファイルが配置されていることを確認します。

    1. プルシークレットが kcli プランと同じフォルダーにあり、プルシークレットファイルの名前が openshift_pull.json であることを確認します。

    2. OpenShift Container Platform 定義を含む kcli プランを mgmt-compact-hub-dual.yaml ファイルに追加します。ご使用の環境に合わせてファイルの内容を更新してください。 

      plan: hub-dual
force: true
version: stable
tag: "4.x.y-x86_64" 1
cluster: "hub-dual"
dualstack: true
domain: dns.base.domain.name
api_ip: 192.168.126.10
ingress_ip: 192.168.126.11
service_networks:
- 172.30.0.0/16
- fd02::/112
cluster_networks:
- 10.132.0.0/14
- fd01::/48
disconnected_url: registry.dns.base.domain.name:5000
disconnected_update: true
disconnected_user: dummy
disconnected_password: dummy
disconnected_operators_version: v4.14
disconnected_operators:
- name: metallb-operator
- name: lvms-operator
  channels:
  - name: stable-4.13
disconnected_extra_images:
- quay.io/user-name/trbsht:latest
- quay.io/user-name/hypershift:BMSelfManage-v4.14-rc-v3
- registry.redhat.io/openshift4/ose-kube-rbac-proxy:v4.10
dualstack: true
disk_size: 200
extra_disks: [200]
memory: 48000
numcpus: 16
ctlplanes: 3
workers: 0
manifests: extra-manifests
metal3: true
network: dual
users_dev: developer
users_devpassword: developer
users_admin: admin
users_adminpassword: admin
metallb_pool: dual-virtual-network
metallb_ranges:
- 192.168.126.150-192.168.126.190
metallb_autoassign: true
apps:
- users
- lvms-operator
- metallb-operator
vmrules:
- hub-bootstrap:
    nets:
    - name: ipv6
      mac: aa:aa:aa:aa:10:07
- hub-ctlplane-0:
    nets:
    - name: ipv6
      mac: aa:aa:aa:aa:10:01
- hub-ctlplane-1:
    nets:
    - name: ipv6
      mac: aa:aa:aa:aa:10:02
- hub-ctlplane-2:
    nets:
    - name: ipv6
      mac: aa:aa:aa:aa:10:03
    1
    4.x.y を、使用するサポートされている OpenShift Container Platform バージョンに置き換えます。

  4. 管理クラスターをプロビジョニングするには、以下のコマンドを入力します。 

    kcli create cluster openshift --pf mgmt-compact-hub-dual.yaml

次に、Web サーバーを設定します。

1.7.12.7.4.1. 関連情報
  • kcli プランファイルのパラメーターの詳細は、kcli 公式ドキュメントの parameters.yml の作成 を参照してください。
1.7.12.7.5. デュアルスタックネットワーク用の Web サーバーの設定

ホステッドクラスターとしてデプロイする OpenShift Container Platform リリースに関連付けられた Red Hat Enterprise Linux CoreOS (RHCOS) イメージをホストするには、追加の Web サーバーを設定する必要があります。

Web サーバーを設定するには、以下の手順を実行します。

  1. 以下のコマンドを入力して、使用する OpenShift Container Platform リリースから openshift-install バイナリーを展開します。 

    oc adm -a ${LOCAL_SECRET_JSON} release extract --command=openshift-install "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}"

  2. 次のスクリプトを実行します。このスクリプトは、/opt/srv ディレクトリーにフォルダーを作成します。このフォルダーには、ワーカーノードをプロビジョニングするための RHCOS イメージが含まれています。 

    #!/bin/bash

WEBSRV_FOLDER=/opt/srv
ROOTFS_IMG_URL="$(./openshift-install coreos print-stream-json | jq -r '.architectures.x86_64.artifacts.metal.formats.pxe.rootfs.location')" 1
LIVE_ISO_URL="$(./openshift-install coreos print-stream-json | jq -r '.architectures.x86_64.artifacts.metal.formats.iso.disk.location')" 2

mkdir -p ${WEBSRV_FOLDER}/images
curl -Lk ${ROOTFS_IMG_URL} -o ${WEBSRV_FOLDER}/images/${ROOTFS_IMG_URL##*/}
curl -Lk ${LIVE_ISO_URL} -o ${WEBSRV_FOLDER}/images/${LIVE_ISO_URL##*/}
chmod -R 755 ${WEBSRV_FOLDER}/*

## Run Webserver
podman ps --noheading | grep -q websrv-ai
if [[ $? == 0 ]];then
    echo "Launching Registry pod..."
    /usr/bin/podman run --name websrv-ai --net host -v /opt/srv:/usr/local/apache2/htdocs:z quay.io/alosadag/httpd:p8080
fi
    1
    ROOTFS_IMG_URL 値は OpenShift CI Release ページにあります。
    2
    LIVE_ISO_URL 値は、OpenShift CI リリースページで確認できます。

ダウンロードが完了すると、コンテナーが実行され、Web サーバー上でイメージをホストします。このコンテナーは公式 HTTPd イメージのバリエーションを使用しているので、IPv6 ネットワークでの動作も可能になります。

1.7.12.7.6. デュアルスタックネットワークのイメージミラーリングの設定

イメージミラーリングは、registry.redhat.com や quay.io などの外部レジストリーからイメージを取得し、プライベートレジストリーに保存するプロセスです。

1.7.12.7.6.1. ミラーリングプロセスの完了

注: ミラーリングプロセスは、レジストリーサーバーの実行後に開始してください。

次の手順では、ImageSetConfiguration オブジェクトを使用するバイナリーである、oc-mirror ツールが使用されます。このファイルで、以下の情報を指定できます。

  • ミラーリングする OpenShift Container Platform バージョン。バージョンは quay.io にあります。
  • ミラーリングする追加の Operator。パッケージは個別に選択します。
  • リポジトリーに追加する追加のイメージ。

イメージのミラーリングを設定するには、以下の手順を実行します。

  1. ${HOME}/.docker/config.json ファイルが、ミラーリング元のレジストリーとイメージのプッシュ先のプライベートレジストリーで更新されていることを確認します。

  2. 次の例を使用して、ミラーリングに使用する ImageSetConfiguration オブジェクトを作成します。環境に合わせて必要に応じて値を置き換えます。 

    apiVersion: mirror.openshift.io/v1alpha2
kind: ImageSetConfiguration
storageConfig:
  registry:
    imageURL: registry.dns.base.domain.name:5000/openshift/release/metadata:latest
mirror:
  platform:
    channels:
    - name: candidate-4.14
      minVersion: 4.x.y-x86_64  1
      maxVersion: 4.x.y-x86_64
      type: ocp
    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.14-rc-v3
  - name: registry.redhat.io/openshift4/ose-kube-rbac-proxy:v4.10
  operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.14
    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
    1
    4.x.y を、使用するサポートされている OpenShift Container Platform バージョンに置き換えます。

  3. 次のコマンドを入力して、ミラーリングプロセスを開始します。 

    oc-mirror --source-skip-tls --config imagesetconfig.yaml docker://${REGISTRY}

    ミラーリングプロセスが完了すると、oc-mirror-workspace/results-XXXXXX/ という名前の新しいフォルダーが作成されます。このフォルダーには、ICSP と、ホステッドクラスターに適用するカタログソースが含まれます。

  4. oc adm release mirror コマンドを使用して、OpenShift Container Platform のナイトリーバージョンまたは CI バージョンをミラーリングします。以下のコマンドを入力します。 

    REGISTRY=registry.$(hostname --long):5000

oc adm release mirror \
  --from=registry.ci.openshift.org/ocp/release:4.x.y-x86_64 \
  --to=${REGISTRY}/openshift/release \
  --to-release-image=${REGISTRY}/openshift/release-images:registry.dns.base.domain.name:5000/openshift/release-images:4.x.y-x86_64

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

  5. 非接続ネットワークへのインストール の手順に従って、最新のマルチクラスターエンジン Operator イメージをミラーリングします。
1.7.12.7.6.2. 管理クラスターでのオブジェクトの適用

ミラーリングプロセスが完了したら、管理クラスターに 2 つのオブジェクトを適用する必要があります。

  • イメージコンテンツソースポリシー (ICSP) またはイメージダイジェストミラーセット (IDMS)
  • カタログソース

oc-mirror ツールを使用すると、出力アーティファクトは oc-mirror-workspace/results-XXXXXX/ という名前のフォルダーに保存されます。

ICSP または IDMS は、ノードを再起動せずに、各ノードで kubelet を再起動する MachineConfig 変更を開始します。ノードが READY としてマークされたら、新しく生成されたカタログソースを適用する必要があります。

カタログソースは、カタログイメージのダウンロードや処理を行い、そのイメージに含まれるすべての PackageManifests を取得するなど、openshift-marketplace Operator でアクションを開始します。

  1. 新しいソースを確認するには、新しい CatalogSource をソースとして使用して次のコマンドを実行します。 

    oc get packagemanifest

  2. アーティファクトを適用するには、次の手順を実行します。

    1. 次のコマンドを入力して、ICSP または IDMS アーティファクトを作成します。 

      oc apply -f oc-mirror-workspace/results-XXXXXX/imageContentSourcePolicy.yaml
    2. ノードの準備が完了するまで待ってから、次のコマンドを入力します。 
    oc apply -f catalogSource-XXXXXXXX-index.yaml

次に、マルチクラスターエンジン Operator をデプロイします。

1.7.12.7.6.3. 関連情報
1.7.12.7.7. デュアルスタックネットワーク用のマルチクラスターエンジン Operator のデプロイ

マルチクラスターエンジン Operator は、プロバイダー間でクラスターをデプロイメントする場合に重要な役割を果たします。Red Hat Advanced Cluster Management をすでにインストールしている場合は、マルチクラスターエンジン Operator は自動的にインストールされるため、インストールする必要はありません。

マルチクラスターエンジン Operator がインストールされていない場合は、次のドキュメントを参照して、前提条件とインストール手順を確認してください。

1.7.12.7.7.1. AgentServiceConfig リソースのデプロイ

AgentServiceConfig カスタムリソースは、マルチクラスターエンジン Operator の一部である Assisted Service アドオンの重要なコンポーネントです。このコンポーネントは、ベアメタルクラスターをデプロイメントします。アドオンが有効な場合に、AgentServiceConfig リソースをデプロイしてアドオンを設定します。

AgentServiceConfig リソースの設定に加えて、マルチクラスターエンジン Operator が非接続環境で適切に機能するように、追加の config map を含める必要があります。

  1. 次の config map を追加してカスタムレジストリーを設定します。これには、デプロイメントをカスタマイズするための非接続環境の情報が含まれています。 

    ---
apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-registries
  namespace: multicluster-engine
  labels:
    app: assisted-service
data:
  ca-bundle.crt: |
    -----BEGIN CERTIFICATE-----
    -----END CERTIFICATE-----
  registries.conf: |
    unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]

    [[registry]]
    prefix = ""
    location = "registry.redhat.io/openshift4"
    mirror-by-digest-only = true

    [[registry.mirror]]
      location = "registry.dns.base.domain.name:5000/openshift4" 1

    [[registry]]
    prefix = ""
    location = "registry.redhat.io/rhacm2"
    mirror-by-digest-only = true
    ...
    ...
    1
    dns.base.domain.name は DNS ベースドメイン名に置き換えます。

    オブジェクトには、以下の 2 つのフィールドが含まれます。

    • カスタム CA: このフィールドには、デプロイメントのさまざまなプロセスに読み込まれる認証局 (CA) が含まれます。
    • レジストリー: Registries.conf フィールドには、元のソースレジストリーではなくミラーレジストリーから使用する必要があるイメージと namespace に関する情報が含まれています。

  2. 次の例に示すように、AssistedServiceConfig オブジェクトを追加して、Assisted Service を設定します。 

    ---
apiVersion: agent-install.openshift.io/v1beta1
kind: AgentServiceConfig
metadata:
  annotations:
    unsupported.agent-install.openshift.io/assisted-service-configmap: assisted-service-config 1
  name: agent
  namespace: multicluster-engine
spec:
  mirrorRegistryRef:
    name: custom-registries 2
  databaseStorage:
    storageClassName: lvms-vg1
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: 10Gi
  filesystemStorage:
    storageClassName: lvms-vg1
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: 20Gi
  osImages: 3
  - cpuArchitecture: x86_64
    openshiftVersion: "4.14"
    rootFSUrl: http://registry.dns.base.domain.name:8080/images/rhcos-414.92.202308281054-0-live-rootfs.x86_64.img 4
    url: http://registry.dns.base.domain.name:8080/images/rhcos-414.92.202308281054-0-live.x86_64.iso
    version: 414.92.202308281054-0
    1
    metadata.annotations["unsupported.agent-install.openshift.io/assisted-service-configmap"] アノテーションは、Operator が動作をカスタマイズするために使用する config map 名を参照します。
    2
    spec.mirrorRegistryRef.name アノテーションは、Assisted Service Operator が使用する非接続のレジストリー情報を含む config map を指します。この config map は、デプロイメントプロセス中にこれらのリソースを追加します。
    3
    spec.osImages フィールドには、この Operator がデプロイできるさまざまなバージョンが含まれています。このフィールドは必須です。この例では、RootFS ファイルと LiveISO ファイルがすでにダウンロードされていることを前提としています。
    4
    rootFSUrl フィールド と url フィールドで、dns.base.domain.name を DNS ベースドメイン名に置き換えます。

  3. すべてのオブジェクトを 1 つのファイルに連結し、管理クラスターに適用し、これらのオブジェクトをデプロイします。起動するには、以下のコマンドを実行します。 

    oc apply -f agentServiceConfig.yaml

    このコマンドは、次の出力例に示すように、2 つの Pod をトリガーします。 

    assisted-image-service-0                               1/1     Running   2             11d 1
assisted-service-668b49548-9m7xw                       2/2     Running   5             11d 2
    1
    assisted-image-service Pod は、デプロイするクラスターごとにカスタマイズされた、Red Hat Enterprise Linux CoreOS (RHCOS) 起動イメージテンプレートを作成します。
    2
    assisted-service は Operator を参照します。
1.7.12.7.8. デュアルスタックネットワークの TLS 証明書の設定

オフライン環境で Hosted Control Plane を設定するプロセスに、いくつかの TLS 証明書が関与します。認証局 (CA) を管理クラスターに追加するには、OpenShift Container Platform コントロールプレーンおよびワーカーノード内の以下のファイルの内容を変更する必要があります。

  • /etc/pki/ca-trust/extracted/pem/
  • /etc/pki/ca-trust/source/anchors
  • /etc/pki/tls/certs/

CA を管理クラスターに追加するには、次の手順を実行します。

  1. OpenShift Container Platform の公式ドキュメントの CA バンドルの更新 の手順を完了します。この方法には、CA を OpenShift Container Platform ノードにデプロイする image-registry-operator の使用が含まれます。

  2. この方法が実際の状況に該当しない場合は、管理クラスター内の openshift-config namespace に user-ca-bundle という名前の config map が含まれているかどうかを確認してください。

    • namespace にその config map が含まれている場合は、次のコマンドを入力します。 

      ## REGISTRY_CERT_PATH=<PATH/TO/YOUR/CERTIFICATE/FILE>
export REGISTRY_CERT_PATH=/opt/registry/certs/domain.crt

oc create configmap user-ca-bundle -n openshift-config --from-file=ca-bundle.crt=${REGISTRY_CERT_PATH}

    • namespace にその config map が含まれていない場合は、以下のコマンドを入力します。 

      ## REGISTRY_CERT_PATH=<PATH/TO/YOUR/CERTIFICATE/FILE>
export REGISTRY_CERT_PATH=/opt/registry/certs/domain.crt
export TMP_FILE=$(mktemp)

oc get cm -n openshift-config user-ca-bundle -ojsonpath='{.data.ca-bundle\.crt}' > ${TMP_FILE}
echo >> ${TMP_FILE}
echo \#registry.$(hostname --long) >> ${TMP_FILE}
cat ${REGISTRY_CERT_PATH} >> ${TMP_FILE}
oc create configmap user-ca-bundle -n openshift-config --from-file=ca-bundle.crt=${TMP_FILE} --dry-run=client -o yaml | kubectl apply -f -
1.7.12.7.9. デュアルスタックネットワーク用のホステッドクラスターのデプロイ

ホステッドクラスターは、コントロールプレーンと API エンドポイントが管理クラスターでホストされている OpenShift Container Platform クラスターです。ホステッドクラスターには、コントロールプレーンとそれに対応するデータプレーンが含まれます。

Red Hat Advanced Cluster Management のコンソールを使用してホステッドクラスターを作成できますが、次の手順ではマニフェストを使用するため、関連するアーティファクトをより柔軟に変更できます。

1.7.12.7.9.1. ホステッドクラスターオブジェクトのデプロイ

この手順では、次の値が使用されます。

  • HostedCluster name: hosted-dual
  • HostedCluster namespace: clusters
  • Disconnected: true
  • Network stack: Dual

通常、HyperShift Operator は HostedControlPlane namespace を作成します。ただし、この場合は、HyperShift Operator が HostedCluster オブジェクトの調整を開始する前に、すべてのオブジェクトを含める必要があります。その後、Operator が調整プロセスを開始すると、所定の場所にあるすべてのオブジェクトを見つけることができます。

  1. namespace に関する次の情報を含めて、YAML ファイルを作成します。 

    ---
apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: null
  name: clusters-hosted-dual
spec: {}
status: {}
---
apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: null
  name: clusters
spec: {}
status: {}

  2. config map とシークレットに関する次の情報を含む YAML ファイルを作成し、HostedCluster デプロイメントに追加します。 

    ---
apiVersion: v1
data:
  ca-bundle.crt: |
    -----BEGIN CERTIFICATE-----
    -----END CERTIFICATE-----
kind: ConfigMap
metadata:
  name: user-ca-bundle
  namespace: clusters
---
apiVersion: v1
data:
  .dockerconfigjson: xxxxxxxxx
kind: Secret
metadata:
  creationTimestamp: null
  name: hosted-dual-pull-secret
  namespace: clusters
---
apiVersion: v1
kind: Secret
metadata:
  name: sshkey-cluster-hosted-dual
  namespace: clusters
stringData:
  id_rsa.pub: ssh-rsa xxxxxxxxx
---
apiVersion: v1
data:
  key: nTPtVBEt03owkrKhIdmSW8jrWRxU57KO/fnZa8oaG0Y=
kind: Secret
metadata:
  creationTimestamp: null
  name: hosted-dual-etcd-encryption-key
  namespace: clusters
type: Opaque

  3. RBAC ロールを含む YAML ファイルを作成し、Assisted Service エージェントが Hosted Control Plane と同じ HostedControlPlane namespace に配置し、引き続きクラスター API で管理されるようにします。 

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  creationTimestamp: null
  name: capi-provider-role
  namespace: clusters-hosted-dual
rules:
- apiGroups:
  - agent-install.openshift.io
  resources:
  - agents
  verbs:
  - '*'

  4. HostedCluster オブジェクトに関する情報を含む YAML ファイルを作成し、必要に応じて値を置き換えます。 

    apiVersion: hypershift.openshift.io/v1beta1
kind: HostedCluster
metadata:
  name: hosted-dual
  namespace: clusters
spec:
  additionalTrustBundle:
    name: "user-ca-bundle"
  olmCatalogPlacement: guest
  imageContentSources: 1
  - source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
    mirrors:
    - registry.dns.base.domain.name:5000/openshift/release 2
  - source: quay.io/openshift-release-dev/ocp-release
    mirrors:
    - registry.dns.base.domain.name:5000/openshift/release-images
  - mirrors:
  ...
  ...
  autoscaling: {}
  controllerAvailabilityPolicy: SingleReplica
  dns:
    baseDomain: dns.base.domain.name
  etcd:
    managed:
      storage:
        persistentVolume:
          size: 8Gi
        restoreSnapshotURL: null
        type: PersistentVolume
    managementType: Managed
  fips: false
  networking:
    clusterNetwork:
    - cidr: 10.132.0.0/14
    - cidr: fd01::/48
    networkType: OVNKubernetes
    serviceNetwork:
    - cidr: 172.31.0.0/16
    - cidr: fd02::/112
  platform:
    agent:
      agentNamespace: clusters-hosted-dual
    type: Agent
  pullSecret:
    name: hosted-dual-pull-secret
  release:
    image: registry.dns.base.domain.name:5000/openshift/release-images:4.x.y-x86_64 3
  secretEncryption:
    aescbc:
      activeKey:
        name: hosted-dual-etcd-encryption-key
    type: aescbc
  services:
  - service: APIServer
    servicePublishingStrategy:
      nodePort:
        address: api.hosted-dual.dns.base.domain.name
      type: NodePort
  - service: OAuthServer
    servicePublishingStrategy:
      nodePort:
        address: api.hosted-dual.dns.base.domain.name
      type: NodePort
  - service: OIDC
    servicePublishingStrategy:
      nodePort:
        address: api.hosted-dual.dns.base.domain.name
      type: NodePort
  - service: Konnectivity
    servicePublishingStrategy:
      nodePort:
        address: api.hosted-dual.dns.base.domain.name
      type: NodePort
  - service: Ignition
    servicePublishingStrategy:
      nodePort:
        address: api.hosted-dual.dns.base.domain.name
      type: NodePort
  sshKey:
    name: sshkey-cluster-hosted-dual
status:
  controlPlaneEndpoint:
    host: ""
    port: 0
    1
    imageContentSources セクションには、ホステッドクラスター内のユーザーワークロードのミラー参照が含まれます。
    2
    YAML ファイル全体で、dns.base.domain.name は、DNS ベースドメイン名に置き換えます。
    3
    4.x.y を、使用するサポートされている OpenShift Container Platform バージョンに置き換えます。

  5. OpenShift Container Platform リリースの HyperShift Operator リリースを指すアノテーションを HostedCluster オブジェクトに追加します。

    1. 次のコマンドを入力して、イメージペイロードを取得します。 

      oc adm release info registry.dns.base.domain.name:5000/openshift-release-dev/ocp-release:4.x.y-x86_64 | grep hypershift

      ここで、dns.base.domain.name は DNS ベースドメイン名であり、4.x.y は使用するサポートされている OpenShift Container Platform のバージョンです。

    2. 以下の出力を参照してください。 

      hypershift                                     sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8

    3. OpenShift Container Platform Images namespace を使用して、次のコマンドを入力してダイジェストを確認します。 

      podman pull registry.dns.base.domain.name:5000/openshift-release-dev/ocp-v4.0-art-dev@sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8

      dns.base.domain.name は DNS ベースドメイン名です。

    4. 以下の出力を参照してください。 

      podman pull registry.dns.base.domain.name:5000/openshift/release@sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8
Trying to pull registry.dns.base.domain.name:5000/openshift/release@sha256:31149e3e5f8c5e5b5b100ff2d89975cf5f7a73801b2c06c639bf6648766117f8...
Getting image source signatures
Copying blob d8190195889e skipped: already exists
Copying blob c71d2589fba7 skipped: already exists
Copying blob d4dc6e74b6ce skipped: already exists
Copying blob 97da74cc6d8f skipped: already exists
Copying blob b70007a560c9 done
Copying config 3a62961e6e done
Writing manifest to image destination
Storing signatures
3a62961e6ed6edab46d5ec8429ff1f41d6bb68de51271f037c6cb8941a007fde

    注: HostedCluster オブジェクトに設定されるリリースイメージでは、タグではなくダイジェストを使用する必要があります (例: quay.io/openshift-release-dev/ocp-release@sha256:e3ba11bd1e5e8ea5a0b36a75791c90f29afb0fdbe4125be4e48f69c76a5c47a0)。

  6. YAML ファイルで定義したすべてのオブジェクトを 1 つのファイルに連結し、管理クラスターに対して適用して作成します。起動するには、以下のコマンドを実行します。 

    oc apply -f 01-4.14-hosted_cluster-nodeport.yaml

  7. Hosted Control Plane の出力を参照してください。 

    NAME                                                  READY   STATUS    RESTARTS   AGE
capi-provider-5b57dbd6d5-pxlqc                        1/1     Running   0          3m57s
catalog-operator-9694884dd-m7zzv                      2/2     Running   0          93s
cluster-api-f98b9467c-9hfrq                           1/1     Running   0          3m57s
cluster-autoscaler-d7f95dd5-d8m5d                     1/1     Running   0          93s
cluster-image-registry-operator-5ff5944b4b-648ht      1/2     Running   0          93s
cluster-network-operator-77b896ddc-wpkq8              1/1     Running   0          94s
cluster-node-tuning-operator-84956cd484-4hfgf         1/1     Running   0          94s
cluster-policy-controller-5fd8595d97-rhbwf            1/1     Running   0          95s
cluster-storage-operator-54dcf584b5-xrnts             1/1     Running   0          93s
cluster-version-operator-9c554b999-l22s7              1/1     Running   0          95s
control-plane-operator-6fdc9c569-t7hr4                1/1     Running   0          3m57s
csi-snapshot-controller-785c6dc77c-8ljmr              1/1     Running   0          77s
csi-snapshot-controller-operator-7c6674bc5b-d9dtp     1/1     Running   0          93s
csi-snapshot-webhook-5b8584875f-2492j                 1/1     Running   0          77s
dns-operator-6874b577f-9tc6b                          1/1     Running   0          94s
etcd-0                                                3/3     Running   0          3m39s
hosted-cluster-config-operator-f5cf5c464-4nmbh        1/1     Running   0          93s
ignition-server-6b689748fc-zdqzk                      1/1     Running   0          95s
ignition-server-proxy-54d4bb9b9b-6zkg7                1/1     Running   0          95s
ingress-operator-6548dc758b-f9gtg                     1/2     Running   0          94s
konnectivity-agent-7767cdc6f5-tw782                   1/1     Running   0          95s
kube-apiserver-7b5799b6c8-9f5bp                       4/4     Running   0          3m7s
kube-controller-manager-5465bc4dd6-zpdlk              1/1     Running   0          44s
kube-scheduler-5dd5f78b94-bbbck                       1/1     Running   0          2m36s
machine-approver-846c69f56-jxvfr                      1/1     Running   0          92s
oauth-openshift-79c7bf44bf-j975g                      2/2     Running   0          62s
olm-operator-767f9584c-4lcl2                          2/2     Running   0          93s
openshift-apiserver-5d469778c6-pl8tj                  3/3     Running   0          2m36s
openshift-controller-manager-6475fdff58-hl4f7         1/1     Running   0          95s
openshift-oauth-apiserver-dbbc5cc5f-98574             2/2     Running   0          95s
openshift-route-controller-manager-5f6997b48f-s9vdc   1/1     Running   0          95s
packageserver-67c87d4d4f-kl7qh                        2/2     Running   0          93s

  8. ホステッドクラスターの出力を確認します。 

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

次に、NodePool オブジェクトを作成します。

1.7.12.7.9.2. ホステッドクラスターの NodePool オブジェクトの作成

NodePool は、ホステッドクラスターに関連付けられたスケーラブルなワーカーノードのセットです。NodePool マシンアーキテクチャーは特定のプール内で一貫性を保ち、コントロールプレーンのマシンアーキテクチャーから独立しています。

  1. NodePool オブジェクトに関する次の情報を含む YAML ファイルを作成し、必要に応じて値を置き換えます。 

    apiVersion: hypershift.openshift.io/v1beta1
kind: NodePool
metadata:
  creationTimestamp: null
  name: hosted-dual
  namespace: clusters
spec:
  arch: amd64
  clusterName: hosted-dual
  management:
    autoRepair: false 1
    upgradeType: InPlace 2
  nodeDrainTimeout: 0s
  platform:
    type: Agent
  release:
    image: registry.dns.base.domain.name:5000/openshift/release-images:4.x.y-x86_64 3
  replicas: 0
status:
  replicas: 0 4
    1
    ノードが削除された場合、ノードは再作成されないため、autoRepair フィールドは false に設定されます。
    2
    upgradeType は InPlace に設定されます。これは、アップグレード中に同じベアメタルノードが再利用されることを示します。
    3
    この NodePool に含まれるすべてのノードは、OpenShift Container Platform バージョン 4.x.y-x86_64 に基づいています。dns.base.domain.name の値を DNS ベースドメイン名に置き換え、4.x.y の値を、使用するサポートされている OpenShift Container Platform のバージョンに置き換えます。
    4
    replicas の値は 0 に設定されているため、必要に応じてスケールを変更できます。すべての手順が完了するまで、NodePool レプリカを 0 に保つことが重要です。

  2. 次のコマンドを入力して、NodePool オブジェクトを作成します。 

    oc apply -f 02-nodepool.yaml

  3. 出力を参照してください。 

    NAMESPACE   NAME          CLUSTER   DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION                              UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
clusters    hosted-dual   hosted    0                               False         False        4.x.y-x86_64

次に、InfraEnv リソースを作成します。

1.7.12.7.9.3. ホステッドクラスターの InfraEnv リソースの作成

InfraEnv リソースは、pullSecretRef や sshAuthorizedKey などの重要な詳細を含む Assisted Service オブジェクトです。これらの詳細は、ホステッドクラスター用にカスタマイズされた Red Hat Enterprise Linux CoreOS (RHCOS) ブートイメージを作成するために使用されます。

  1. InfraEnv リソースに関する次の情報を含めて YAML ファイルを作成し、必要に応じて値を置き換えます。 

    ---
apiVersion: agent-install.openshift.io/v1beta1
kind: InfraEnv
metadata:
  name: hosted-dual
  namespace: clusters-hosted-dual
spec:
  pullSecretRef: 1
    name: pull-secret
  sshAuthorizedKey: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDk7ICaUE+/k4zTpxLk4+xFdHi4ZuDi5qjeF52afsNkw0w/glILHhwpL5gnp5WkRuL8GwJuZ1VqLC9EKrdmegn4MrmUlq7WTsP0VFOZFBfq2XRUxo1wrRdor2z0Bbh93ytR+ZsDbbLlGngXaMa0Vbt+z74FqlcajbHTZ6zBmTpBVq5RHtDPgKITdpE1fongp7+ZXQNBlkaavaqv8bnyrP4BWahLP4iO9/xJF9lQYboYwEEDzmnKLMW1VtCE6nJzEgWCufACTbxpNS7GvKtoHT/OVzw8ArEXhZXQUS1UY8zKsX2iXwmyhw5Sj6YboA8WICs4z+TrFP89LmxXY0j6536TQFyRz1iB4WWvCbH5n6W+ABV2e8ssJB1AmEy8QYNwpJQJNpSxzoKBjI73XxvPYYC/IjPFMySwZqrSZCkJYqQ023ySkaQxWZT7in4KeMu7eS2tC+Kn4deJ7KwwUycx8n6RHMeD8Qg9flTHCv3gmab8JKZJqN3hW1D378JuvmIX4V0= 2
    1
    pullSecretRef は、プルシークレットが使用される InfraEnv と同じ namespace 内の config map を参照します。
    2
    sshAuthorizedKey は、ブートイメージに配置される SSH 公開鍵を表します。SSH 鍵を使用すると、core ユーザーとしてワーカーノードにアクセスできます。

  2. 次のコマンドを入力して、InfraEnv リソースを作成します。 

    oc apply -f 03-infraenv.yaml

  3. 以下の出力を参照してください。 

    NAMESPACE              NAME     ISO CREATED AT
clusters-hosted-dual   hosted   2023-09-11T15:14:10Z

次に、ワーカーノードを作成します。

1.7.12.7.9.4. ホステッドクラスター用のワーカーノードの作成

ベアメタルプラットフォームで作業している場合、BareMetalHost の詳細が正しく設定されていることを確認するためにワーカーノードを作成することが重要です。

仮想マシンを使用している場合は、次の手順を実行して、Metal3 Operator が使用する空のワーカーノードを作成できます。これには、kcli ツールを使用します。

  1. ワーカーノードを作成するのが初めてではない場合は、まず以前の設定を削除する必要があります。これには、次のコマンドを入力してプランを削除します。 

    kcli delete plan hosted-dual
    1. プランを削除するかどうかを確認するプロンプトが表示されたら、y と入力します。
    2. プランが削除されたことを示すメッセージが表示されることを確認します。

  2. 次のコマンドを入力して仮想マシンを作成します。 

    kcli create vm -P start=False -P uefi_legacy=true -P plan=hosted-dual -P memory=8192 -P numcpus=16 -P disks=[200,200] -P nets=["{\"name\": \"dual\", \"mac\": \"aa:aa:aa:aa:11:01\"}"] -P uuid=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa1101 -P name=hosted-dual-worker0
    kcli create vm -P start=False -P uefi_legacy=true -P plan=hosted-dual -P memory=8192 -P numcpus=16 -P disks=[200,200] -P nets=["{\"name\": \"dual\", \"mac\": \"aa:aa:aa:aa:11:02\"}"] -P uuid=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa1102 -P name=hosted-dual-worker1
    kcli create vm -P start=False -P uefi_legacy=true -P plan=hosted-dual -P memory=8192 -P numcpus=16 -P disks=[200,200] -P nets=["{\"name\": \"dual\", \"mac\": \"aa:aa:aa:aa:11:03\"}"] -P uuid=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa1103 -P name=hosted-dual-worker2
    systemctl restart ksushy

    ここでは、以下のようになります。

    • start=False は、仮想マシン (VM) が作成時に自動的に起動しないことを意味します。
    • uefi_legacy=true は、以前の UEFI 実装との互換性を確保するために UEFI レガシーブートを使用することを意味します。
    • plan=hosted-dual は、マシンのグループをクラスターとして識別するプラン名を示します。
    • memory=8192 および numcpus=16 は、RAM や CPU などの仮想マシンのリソースを指定するパラメーターです。
    • disks=[200,200] は、VM 内に 2 つのシンプロビジョニングディスクを作成していることを示します。
    • nets=[{"name": "dual", "mac": "aa:aa:aa:aa:02:13"}] は、接続するネットワーク名やプライマリーインターフェイスの MAC アドレスなど、ネットワークの詳細です。
    • restart ksushy は、ksushy ツールを再起動して、追加した VM をツールが確実に検出できるようにします。

  3. 結果の出力を確認します。 

    +---------------------+--------+-------------------+----------------------------------------------------+-------------+---------+
|         Name        | Status |         Ip        |                       Source                       |     Plan    | Profile |
+---------------------+--------+-------------------+----------------------------------------------------+-------------+---------+
|    hosted-worker0   |  down  |                   |                                                    | hosted-dual |  kvirt  |
|    hosted-worker1   |  down  |                   |                                                    | hosted-dual |  kvirt  |
|    hosted-worker2   |  down  |                   |                                                    | hosted-dual |  kvirt  |
+---------------------+--------+-------------------+----------------------------------------------------+-------------+---------+

次に、ホステッドクラスターのベアメタルホストを作成します。

1.7.12.7.9.5. ホステッドクラスターのベアメタルホスト作成

ベアメタルホスト は、物理的な詳細と論理詳細を含む openshift-machine-api オブジェクトで、Metal3 Operator によって識別できるようになっています。これらの詳細は、agents と呼ばれる他の Assisted Service オブジェクトに関連付けられています。

重要: ベアメタルホストと移行先ノードを作成する前に、仮想マシンを作成する必要があります。

ベアメタルホストを作成するには、以下の手順を実行します。

  1. 次の情報を使用して YAML ファイルを作成します。

    注記: ベアメタルホストの認証情報を保持するシークレットが 1 つ以上あるため、ワーカーノードごとに少なくとも 2 つのオブジェクトを作成する必要があります。 

    ---
apiVersion: v1
kind: Secret
metadata:
  name: hosted-dual-worker0-bmc-secret
  namespace: clusters-hosted-dual
data:
  password: YWRtaW4=
  username: YWRtaW4=
type: Opaque
---
apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: hosted-dual-worker0
  namespace: clusters-hosted-dual
  labels:
    infraenvs.agent-install.openshift.io: hosted-dual 1
  annotations:
    inspect.metal3.io: disabled
    bmac.agent-install.openshift.io/hostname: hosted-dual-worker0 2
spec:
  automatedCleaningMode: disabled 3
  bmc:
    disableCertificateVerification: true 4
    address: redfish-virtualmedia://[192.168.126.1]:9000/redfish/v1/Systems/local/hosted-dual-worker0 5
    credentialsName: hosted-dual-worker0-bmc-secret 6
  bootMACAddress: aa:aa:aa:aa:02:11 7
  online: true 8
    1
    infraenvs.agent-install.openshift.io は、Assisted Installer オブジェクトと BareMetalHost オブジェクト間のリンクとして機能します。
    2
    bmac.agent-install.openshift.io/hostname は、デプロイメント中に採用されるノード名を表します。
    3
    automatedCleaningMode は、ノードが Metal3 Operator によって消去されるのを防ぎます。
    4
    disableCertificateVerification は true に設定され、クライアントから証明書の検証がバイパスされます。
    5
    address は、ワーカーノードのベースボード管理コントローラー (BMC) アドレスを示します。
    6
    credentialsName は、ユーザーとパスワードの認証情報が保存されるシークレットを指します。
    7
    bootMACAddress は、ノードの起動元のインターフェイス MAC アドレスを示します。
    8
    online は、BareMetalHost オブジェクトが作成された後のノードの状態を定義します。

  2. 次のコマンドを入力して、BareMetalHost オブジェクトをデプロイします。 

    oc apply -f 04-bmh.yaml

    プロセス中に、次の出力が確認できます。

    • この出力は、プロセスがノードに到達しようとしていることを示しています。 

      NAMESPACE         NAME             STATE         CONSUMER   ONLINE   ERROR   AGE
clusters-hosted   hosted-worker0   registering              true             2s
clusters-hosted   hosted-worker1   registering              true             2s
clusters-hosted   hosted-worker2   registering              true             2s

    • この出力は、ノードが起動していることを示しています。 

      NAMESPACE         NAME             STATE          CONSUMER   ONLINE   ERROR   AGE
clusters-hosted   hosted-worker0   provisioning              true             16s
clusters-hosted   hosted-worker1   provisioning              true             16s
clusters-hosted   hosted-worker2   provisioning              true             16s
    • この出力は、ノードが正常に起動したことを示しています。 
    NAMESPACE         NAME             STATE         CONSUMER   ONLINE   ERROR   AGE
clusters-hosted   hosted-worker0   provisioned              true             67s
clusters-hosted   hosted-worker1   provisioned              true             67s
clusters-hosted   hosted-worker2   provisioned              true             67s

  3. ノードが起動したら、次の例に示すように、namespace のエージェントに注目してください。 

    NAMESPACE         NAME                                   CLUSTER   APPROVED   ROLE          STAGE
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0411             true       auto-assign
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0412             true       auto-assign
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0413             true       auto-assign

    エージェントは、インストールに使用できるノードを表します。ホステッドクラスターにノードを割り当てるには、ノードプールをスケールアップします。

1.7.12.7.9.6. ノードプールのスケールアップ

ベアメタルホストを作成すると、そのステータスが Registering Provisioning、Provisioned に変わります。ノードは、エージェントの LiveISO と、agent という名前のデフォルトの Pod で始まります。このエージェントは、Assisted Service Operator から OpenShift Container Platform ペイロードをインストールする指示を受け取ります。

  1. ノードプールをスケールアップするには、次のコマンドを入力します。 

    oc -n clusters scale nodepool hosted-dual --replicas 3

  2. スケーリングプロセスが完了すると、エージェントがホステッドクラスターに割り当てられていることがわかります。 

    NAMESPACE         NAME                                   CLUSTER   APPROVED   ROLE          STAGE
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0411   hosted    true       auto-assign
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0412   hosted    true       auto-assign
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0413   hosted    true       auto-assign

  3. また、ノードプールレプリカが設定されていることにも注意してください。 

    NAMESPACE   NAME     CLUSTER   DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION                              UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
clusters    hosted   hosted    3                               False         False        4.x.y-x86_64                                      Minimum availability requires 3 replicas, current 0 available

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

  4. ノードがクラスターに参加するまで待ちます。プロセス中に、エージェントはステージとステータスに関する最新情報を提供します。

次に、ホステッドクラスターのデプロイメントを監視します。

1.7.12.7.10. デュアルスタックネットワークのホステッドクラスターデプロイメントの終了

ホステッドクラスターのデプロイメントは、コントロールプレーンとデータプレーンの 2 つの観点から監視できます。

1.7.12.7.10.1. コントロールプレーンを使用してホストされたクラスターのデプロイメントを監視する

コントロールプレーンを使用して、ホストされたクラスターのデプロイメントを監視できます。

  1. 次のコマンドを入力して、ホストされたクラスターの kubeconfig ファイルをエクスポートします。 

    export KUBECONFIG=<path_to_hosted_cluster_kubeconfig>

  2. 次のコマンドを入力して、ホストされたクラスターのデプロイメントの進行状況を確認します。 

    watch "oc get pod -n hypershift;echo;echo;oc get pod -n <hosted_control_plane_namespace>;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;"

このコマンドは、次のアーティファクトに関する情報を提供します。

  • HyperShift Operator
  • HostedControlPlane Pod
  • ベアメタルホスト
  • エージェント
  • InfraEnv リソース
  • HostedCluster および NodePool リソース
1.7.12.7.10.2. データプレーンを使用してホストされたクラスターのデプロイメントを監視する

データプレーンを使用して、ホストされたクラスターのデプロイメントプロセス中に Operator がどのように進行しているかを監視できます。

  1. 次のコマンドを入力して、ホストされたクラスターの kubeconfig ファイルを作成します。 

    hcp create kubeconfig --name <hosted_cluster_name> --namespace <hosted_cluster_namespace>

  2. 次のコマンドを入力して、ホストされたクラスターの kubeconfig ファイルをエクスポートします。 

    export KUBECONFIG=<path_to_hosted_cluster_kubeconfig>

  3. 次のコマンドを入力して、クラスターバージョン、ノード、およびクラスター Operator のステータスを確認します。 

    watch "oc get clusterversion,nodes,co"

1.7.13. Hosted Control Plane クラスターの手動インポート

ホステッドクラスターは、Hosted Control Plane が使用可能になった後、マルチクラスターエンジン Operator に自動的にインポートされます。ホステッドクラスターを手動でインポートする場合は、次の手順を実行します。

  1. Infrastructure > Clusters をクリックし、インポートするホステッドクラスターを選択します。

  2. Import hosted cluster をクリックします。

    注記: 検出された ホステッドクラスターについては、コンソールからインポートすることもできますが、クラスターはアップグレード可能な状態である必要があります。Hosted Control Plane を使用できないため、ホステッドクラスターがアップグレード可能な状態ではない場合、クラスターへのインポートは無効になります。Import をクリックして、プロセスを開始します。クラスターが更新を受信している間、ステータスは Importing であり、その後、Ready に変わります。

1.7.13.1. Hosted Control Plane クラスターの AWS での手動インポート

次の手順を実行することで、コマンドラインインターフェイスを使用して、ホストされているコントロールプレーンクラスターを AWS にインポートすることもできます。

  1. 以下のサンプル YAML ファイルを使用して、ManagedCluster リソースを作成します。 

    apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  annotations:
    import.open-cluster-management.io/hosting-cluster-name: local-cluster
    import.open-cluster-management.io/klusterlet-deploy-mode: Hosted
    open-cluster-management/created-via: hypershift
  labels:
    cloud: auto-detect
    cluster.open-cluster-management.io/clusterset: default
    name: <cluster_name>
    vendor: OpenShift
  name: <cluster_name>
spec:
  hubAcceptsClient: true
  leaseDurationSeconds: 60

    <cluster_name> は、ホステッドクラスターの名前に置き換えます。

  2. 以下のコマンドを実行してリソースを適用します。 

    oc apply -f <file_name>

    <file_name> を、直前の手順で作成した YAML ファイル名に置き換えます。

  3. 以下のサンプル YAML ファイルを使用して、KlusterletAddonConfig リソースを作成します。これは、Red Hat Advanced Cluster Management にのみ適用されます。マルチクラスターエンジン Operator のみをインストールした場合は、この手順を省略します。 

    apiVersion: agent.open-cluster-management.io/v1
kind: KlusterletAddonConfig
metadata:
  name: <cluster_name>
  namespace: <cluster_name>
spec:
  clusterName: <cluster_name>
  clusterNamespace: <cluster_name>
  clusterLabels:
    cloud: auto-detect
    vendor: auto-detect
  applicationManager:
    enabled: true
  certPolicyController:
    enabled: true
  iamPolicyController:
    enabled: true
  policyController:
    enabled: true
  searchCollector:
    enabled: false

    <cluster_name> は、ホステッドクラスターの名前に置き換えます。

  4. 以下のコマンドを実行してリソースを適用します。 

    oc apply -f <file_name>

    <file_name> を、直前の手順で作成した YAML ファイル名に置き換えます。

  5. インポートプロセスが完了すると、ホステッドクラスターがコンソールに表示されます。以下のコマンドを実行して、ホステッドクラスターのステータスを確認することもできます。 

    oc get managedcluster <cluster_name>

1.7.13.2. 関連情報

1.7.13.3. ホステッドクラスターのマルチクラスターエンジン Operator への自動インポートを無効にする

コントロールプレーンが使用可能になった後、ホステッドクラスターがマルチクラスターエンジン Operator に自動的にインポートされます。

自動インポートを無効にしても、以前にインポートされたホステッドクラスターは影響を受けません。マルチクラスターエンジン Operator 2.5 にアップグレードし、自動インポートが有効になっている場合、コントロールプレーンが使用可能な場合、インポートされていないすべてのホストクラスターが自動的にインポートされます。

注記: Red Hat Advanced Cluster Management がインストールされている場合は、すべての Red Hat Advanced Cluster Management アドオンも有効になります。

自動インポートが無効になっている場合、新しく作成されたホステッドクラスターのみが自動的にインポートされません。すでにインポートされているホステッドクラスターは影響を受けません。コンソールを使用するか、ManagedCluster および KlusterletAddonConfig カスタムリソースを作成することにより、クラスターを手動でインポートすることもできます。

ホステッドクラスターの自動インポートを無効にするには、次の手順を実行します。

  1. マルチクラスターエンジン Operator ハブクラスターで、AddonDeploymentConfig リソースを開き、multicluster-engine namespace の hypershift-addon-deploy-config 仕様を編集します。以下のコマンドを入力します。 

    oc edit addondeploymentconfig hypershift-addon-deploy-config -n multicluster-engine

  2. 次の例に示すように、spec.customizedVariables セクションで、値が "true" の autoImportDisabled 変数を追加します。 

    apiVersion: addon.open-cluster-management.io/v1alpha1
kind: AddOnDeploymentConfig
metadata:
  name: hypershift-addon-deploy-config
  namespace: multicluster-engine
spec:
  customizedVariables:
  - name: autoImportDisabled
    value: "true"
  3. 自動インポートを再度有効にするには、autoImportDisabled 変数の値を "false" に設定するか、AddonDeploymentConfig リソースから変数を削除します。
1.7.13.3.1. 関連情報

ホステッドクラスターを手動でインポートする手順は、Hosted Control Plane クラスターの手動インポート を参照してください。

1.7.14. Hosted Control Plane 機能の有効化または無効化

Hosted Control Plane 機能と hypershift-addon マネージドクラスターアドオンは、デフォルトで有効になっています。機能を無効にする場合、または機能を無効にして手動で有効にする必要がある場合は、次の手順を参照してください。

1.7.14.1. Hosted Control Plane 機能を手動での有効化

  1. 次のコマンドを実行して、以下の機能を有効にすることができます。 

    oc patch mce multiclusterengine --type=merge -p '{"spec":{"overrides":{"components":[{"name":"hypershift","enabled": true}]}}}' 1
    1
    デフォルトの MultiClusterEngine リソースインスタンス名は multiclusterengine ですが、$ oc get mce コマンドを実行し、クラスターから MultiClusterEngine 名を取得できます。

  2. 次のコマンドを実行して、hypershift および hypershift-local-hosting 機能が MultiClusterEngine カスタムリソースで有効になっていることを確認します。 

    oc get mce multiclusterengine -o yaml 1
    1
    デフォルトの MultiClusterEngine リソースインスタンス名は multiclusterengine ですが、$ oc get mce コマンドを実行し、クラスターから MultiClusterEngine 名を取得できます。

    出力は以下の例のようになります。 

    apiVersion: multicluster.openshift.io/v1
kind: MultiClusterEngine
metadata:
  name: multiclusterengine
spec:
  overrides:
    components:
    - name: hypershift
      enabled: true
    - name: hypershift-local-hosting
      enabled: true
1.7.14.1.1. local-cluster の hypershift-addon マネージドクラスターアドオンを手動で有効にする

Hosted Control Plane 機能を有効にすると、hypershift-addon マネージドクラスターアドオンが自動的に有効になります。hypershift-addon マネージドクラスターアドオンを手動で有効にする必要がある場合は、次の手順を実行して hypershift-addon を使用し、HyperShift Operator を local-cluster にインストールします。

  1. 以下の例のようなファイルを作成して、ManagedClusterAddon HyperShift アドオンを作成します。 

    apiVersion: addon.open-cluster-management.io/v1alpha1
kind: ManagedClusterAddOn
metadata:
  name: hypershift-addon
  namespace: local-cluster
spec:
  installNamespace: open-cluster-management-agent-addon

  2. 以下のコマンドを実行してこのファイルを適用します。 

    oc apply -f <filename>

    filename は、作成したファイル名に置き換えます。

  3. 以下のコマンドを実行して、hypershift-addon がインストールされていることを確認します。 

    oc get managedclusteraddons -n local-cluster hypershift-addon

    アドオンがインストールされている場合、出力は以下の例のようになります。 

    NAME               AVAILABLE   DEGRADED   PROGRESSING
hypershift-addon   True

HyperShift アドオンがインストールされ、ホスティングクラスターを使用してホステッドクラスターを作成および管理できるようになります。

1.7.14.2. Hosted Control Plane 機能の無効化

HyperShift Operator をアンインストールして、Hosted Control Plane を無効にすることができます。Hosted Control Plane クラスター機能を無効にする場合は、Hosted Control Plane クラスターの管理 トピックで説明されているとおり、マルチクラスターエンジン Operator でホステッドクラスターとマネージドクラスターリソースを破棄する必要があります。

1.7.14.2.1. HyperShift Operator のアンインストール

HyperShift Operator をアンインストールし、local-cluster から hypershift-addon を無効にするには、以下の手順を実行します。

  1. 以下のコマンドを実行して、ホステッドクラスターが実行されていないことを確認します。 

    oc get hostedcluster -A

    重要: ホステッドクラスターが実行されている場合、hypershift-addon が無効になっていても、HyperShift Operator はアンインストールされません。

  2. 以下のコマンドを実行して hypershift-addon を無効にします。 

    oc patch mce multiclusterengine --type=merge -p '{"spec":{"overrides":{"components":[{"name":"hypershift-local-hosting","enabled": false}]}}}' 1
    1
    デフォルトの MultiClusterEngine リソースインスタンス名は multiclusterengine ですが、$ oc get mce コマンドを実行し、クラスターから MultiClusterEngine 名を取得できます。

    注記: hypershift-addon を無効にした後、マルチクラスターエンジン Operator コンソールから local-cluster の hypershift-addon を無効にすることもできます。

1.7.14.2.2. Hosted Control Plane 機能の無効化

Hosted Control Plane 機能を無効にする前に、まず HyperShift Operator をアンインストールする必要があります。次のコマンドを実行して、Hosted Control Plane 機能を無効にします。 

oc patch mce multiclusterengine --type=merge -p '{"spec":{"overrides":{"components":[{"name":"hypershift","enabled": false}]}}}' 1
1
デフォルトの MultiClusterEngine リソースインスタンス名は multiclusterengine ですが、$ oc get mce コマンドを実行し、クラスターから MultiClusterEngine 名を取得できます。

次のコマンドを実行すると、MultiClusterEngine カスタムリソースで hypershift および hypershift-local-hosting 機能が無効になっていることを確認できます。 

oc get mce multiclusterengine -o yaml 1
1
デフォルトの MultiClusterEngine リソースインスタンス名は multiclusterengine ですが、$ oc get mce コマンドを実行し、クラスターから MultiClusterEngine 名を取得できます。

hypershift と hypershift-local-hosting の enabled: フラグが false に設定されている次の例を参照してください。 

apiVersion: multicluster.openshift.io/v1
kind: MultiClusterEngine
metadata:
  name: multiclusterengine
spec:
  overrides:
    components:
    - name: hypershift
      enabled: false
    - name: hypershift-local-hosting
      enabled: false

1.7.14.3. 関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.