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

14.2. 前提条件

OpenShift Container Platform の installer-provisioned installation には、以下が必要です。

  1. 1 つの Red Hat Enterprise Linux (RHEL) 9.x がインストールされているプロビジョナーノード。プロビジョナーは、インストール後に削除できます。
  2. 3 つのコントロールプレーンノード
  3. ベースボード管理コントローラー (BMC) の各ノードへのアクセス。

  4. 1 つ以上のネットワーク:

    1. 1 つの必須のルーティング可能なネットワーク
    2. 1 つのオプションのプロビジョニングネットワーク
    3. 1 つのオプションの管理ネットワーク

OpenShift Container Platform の installer-provisioned installation を開始する前に、ハードウェア環境が以下の要件を満たしていることを確認してください。

14.2.1. ノードの要件

installer-provisioned installation には、ハードウェアノードの各種の要件があります。

  • CPU architecture: すべてのノードは x86_64 または aarch64 CPU アーキテクチャーを使用する必要があります。
  • 同様のノード: Red Hat では、ノードにロールごとに同じ設定を指定することを推奨しています。つまり Red Hat では、同じ CPU、メモリー、ストレージ設定の同じブランドおよびモデルのノードを使用することを推奨しています。
  • ベースボード管理コントローラー: provisioner ノードは、各 OpenShift Container Platform クラスターノードのベースボード管理コントローラー (BMC) にアクセスできる必要があります。IPMI、Redfish、または独自のプロトコルを使用できます。
  • 最新の生成: ノードは最新の生成されたノードである必要があります。installer-provisioned installation は、ノード間で互換性を確保する必要のある BMC プロトコルに依存します。また、RHEL 9 には RAID コントローラーの最新のドライバーが同梱されています。ノードが、provisioner ノードの RHEL 9.x と、コントロールプレーンおよびワーカーノードの RHCOS 9.x をサポートするために必要な新しいバージョンのノードでであることを確認します。
  • レジストリーノード: (オプション) 非接続のミラーリングされていないレジストリーを設定する場合、レジストリーは独自のノードに置くことが推奨されます。
  • プロビジョナーノード: installer-provisioned installation には 1 つの provisioner ノードが必要です。
  • コントロールプレーン: installer-provisioned installation には、高可用性を実現するために 3 つのコントロールプレーンノードが必要です。3 つのコントロールプレーンノードのみで OpenShift Container Platform クラスターをデプロイして、コントロールプレーンノードをワーカーノードとしてスケジュール可能にすることができます。小規模なクラスターでは、開発、実稼働およびテスト時の管理者および開発者に対するリソース効率が高くなります。

  • ワーカーノード: 必須ではありませんが、一般的な実稼働クラスターには複数のワーカーノードがあります。

    重要

    ワーカーノードが 1 つしかないクラスターは、パフォーマンスが低下した状態のルーターおよび Ingress トラフィックでデプロイされるので、デプロイしないでください。

  • ネットワークインターフェイス: 各ノードでは、ルーティング可能な baremetal ネットワークに 1 つ以上のネットワークインターフェイスが必要です。デプロイメントに provisioning ネットワークを使用する場合、各ノードに provisioning ネットワーク用に 1 つのネットワークインターフェイスが必要になります。provisioning ネットワークの使用はデフォルト設定です。

    注記

    同じサブネット上の 1 つのネットワークカード (NIC) のみが、ゲートウェイ経由でトラフィックをルーティングできます。デフォルトでは、アドレス解決プロトコル (ARP) は番号が最も小さい NIC を使用します。ネットワーク負荷分散が期待どおりに機能するようにするには、同じサブネット内の各ノードに 1 つの NIC を使用します。同じサブネット内のノードに複数の NIC を使用する場合は、単一のボンディングまたはチームインターフェイスを使用します。次に、エイリアス IP アドレスの形式で他の IP アドレスをそのインターフェイスに追加します。ネットワークインターフェイスレベルでフォールトトレランスまたは負荷分散が必要な場合は、ボンディングまたはチームインターフェイスでエイリアス IP アドレスを使用します。または、同じサブネットでセカンダリー NIC を無効にするか、IP アドレスがないことを確認できます。

  • Unified Extensible Firmware Interface (UEFI): installer-provisioned installation では、provisioning ネットワークで IPv6 アドレスを使用する場合に、すべての OpenShift Container Platform ノードで UEFI ブートが必要になります。さらに、UEFI Device PXE Settings (UEFI デバイス PXE 設定) は provisioning ネットワーク NIC で IPv6 プロトコルを使用するように設定する必要がありますが、provisioning ネットワークを省略すると、この要件はなくなります。

    重要

    ISO イメージなどの仮想メディアからインストールを開始する場合は、古い UEFI ブートテーブルエントリーをすべて削除します。ブートテーブルに、ファームウェアによって提供される一般的なエントリーではないエントリーが含まれている場合、インストールは失敗する可能性があります。

  • Secure Boot: 多くの実稼働シナリオでは、UEFI ファームウェアドライバー、EFI アプリケーション、オペレーティングシステムなど、信頼できるソフトウェアのみを使用してノードが起動することを確認するために、Secure Boot が有効にされているノードが必要です。手動またはマネージドの Secure Boot を使用してデプロイすることができます。

    1. 手動: 手動で Secure Boot を使用して OpenShift Container Platform クラスターをデプロイするには、UEFI ブートモードおよび Secure Boot を各コントロールプレーンノードおよび各ワーカーノードで有効にする必要があります。Red Hat は、installer-provisioned installation で Redfish 仮想メディアを使用している場合にのみ、手動で有効にした UEFI および Secure Boot で、Secure Boot をサポートします。詳細は、「ノードの設定」セクションの「手動での Secure Boot のノードの設定」を参照してください。

    2. マネージド: マネージド Secure Boot で OpenShift Container Platform クラスターをデプロイするには、install-config.yaml ファイルで bootMode の値を UEFISecureBoot に設定する必要があります。Red Hat は、第 10 世代 HPE ハードウェアおよび 13 世代 Dell ハードウェア (ファームウェアバージョン 2.75.75.75 以上を実行) でマネージド Secure Boot を使用した installer-provisioned installation のみをサポートします。マネージド Secure Boot を使用したデプロイには、Redfish 仮想メディアは必要ありません。詳細は、「OpenShift インストールの環境のセットアップ」セクションの「マネージド Secure Boot の設定」を参照してください。

      注記

      Red Hat は、自己生成したキーを使用する Secure Boot をサポートしません。

14.2.2. クラスターインストールの最小リソース要件

それぞれのクラスターマシンは、以下の最小要件を満たしている必要があります。

表14.1 最小リソース要件
マシンオペレーティングシステムCPU [1]RAMストレージ1 秒あたりの入出力 (IOPS) [2]

ブートストラップ

RHEL

4

16 GB

100 GB

300

コントロールプレーン

RHCOS

4

16 GB

100 GB

300

Compute

RHCOS

2

8 GB

100 GB

300

  1. 1 つの CPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効にされている場合、以下の数式を使用して対応する比率を計算します: (コアごとのスレッド × コア数) × ソケット数 = CPU
  2. OpenShift Container Platform と Kubernetes は、ディスクのパフォーマンスの影響を受けるため、特にコントロールプレーンノードの etcd には、より高速なストレージが推奨されます。多くのクラウドプラットフォームでは、ストレージサイズと IOPS スケールが一緒にあるため、十分なパフォーマンスを得るためにストレージボリュームの割り当てが必要になる場合があります。
注記

OpenShift Container Platform バージョン 4.13 の時点で、RHCOS は RHEL バージョン 9.2 に基づいており、マイクロアーキテクチャーの要件を更新します。次のリストには、各アーキテクチャーに必要な最小限の命令セットアーキテクチャー (ISA) が含まれています。

  • x86-64 アーキテクチャーには x86-64-v2 ISA が必要
  • ARM64 アーキテクチャーには ARMv8.0-A ISA が必要
  • IBM Power アーキテクチャーには Power 9 ISA が必要
  • s390x アーキテクチャーには z14 ISA が必要

詳細は、RHEL アーキテクチャー を参照してください。

プラットフォームのインスタンスタイプがクラスターマシンの最小要件を満たす場合、これは OpenShift Container Platform で使用することがサポートされます。

14.2.3. OpenShift 仮想化のためのベアメタルクラスターの計画

OpenShift 仮想化を使用する場合は、ベアメタルクラスターをインストールする前に、いくつかの要件を認識することが重要です。

  • ライブマイグレーション機能を使用する場合は、クラスターのインストール時に 複数のワーカーノードが必要です。これは、ライブマイグレーションではクラスターレベルの高可用性 (HA) フラグを true に設定する必要があるためです。HA フラグは、クラスターのインストール時に設定され、後で変更することはできません。クラスターのインストール時に定義されたワーカーノードが 2 つ未満の場合、クラスターの存続期間中、HA フラグは false に設定されます。

    注記

    単一ノードのクラスターに OpenShift Virtualization をインストールできますが、単一ノードの OpenShift は高可用性をサポートしていません。

  • ライブマイグレーションには共有ストレージが必要です。OpenShift Virtualization のストレージは、ReadWriteMany (RWX) アクセスモードをサポートし、使用する必要があります。
  • Single Root I/O Virtualization (SR-IOV) を使用する予定の場合は、ネットワークインターフェイスコントローラー (NIC) が OpenShift Container Platform でサポートされていることを確認してください。

関連情報

14.2.4. 仮想メディアを使用したインストールのファームウェア要件

installer-provisioned OpenShift Container Platform クラスターのインストールプログラムは、Redfish 仮想メディアとのハードウェアおよびファームウェアの互換性を検証します。ノードファームウェアに互換性がない場合、インストールプログラムはノードへのインストールを開始しません。以下の表は、Redfish 仮想メディアを使用してデプロイされる installer-provisioned OpenShift Container Platform クラスターで機能するようにテストおよび検証された最小ファームウェアバージョンの一覧です。

注記

Red Hat は、ファームウェア、ハードウェア、またはその他のサードパーティーコンポーネントの組み合わせをすべてテストしません。サードパーティーサポートの詳細は、Red Hat サードパーティーサポートポリシー を参照してください。ファームウェアの更新については、ノードのハードウェアドキュメントを参照するか、ハードウェアベンダーにお問い合わせください。

表14.2 HP ハードウェアと Redfish 仮想メディアのファームウェアの互換性
モデル管理ファームウェアのバージョン

第 10 世代

iLO5

2.63 以降

表14.3 Redfish 仮想メディアを使用した Dell ハードウェアのファームウェアの互換性
モデル管理ファームウェアのバージョン

第 15 世代

iDRAC 9

v6.10.30.00

第 14 世代

iDRAC 9

v6.10.30.00

第 13 世代

iDRAC 8

v2.75.75.75 以降

関連情報

BMC を使用して、新しいベアメタルホストを検出できない

14.2.5. ネットワーク要件

OpenShift Container Platform の installer-provisioned installation には、複数のネットワーク要件があります。まず、installer-provisioned installation では、各ベアメタルノードにオペレーティングシステムをプロビジョニングするためのルーティング不可能な provisioning ネットワークをオプションで使用します。次に、installer-provisioned installation では、ルーティング可能な baremetal ネットワークを使用します。

installer-provisioned ネットワーク

14.2.5.1. 必須ポートが開いていることを確認する

クラスター間で特定のノードが開いてなければ、installer-provisioned によるインストールは正常に完了しません。ファーエッジワーカーノードに別のサブネットを使用する場合などの特定の状況では、これらのサブネット内のノードが、次の必須ポートで他のサブネット内のノードと通信できることを確認する必要があります。

表14.4 必須ポート
ポート説明

67、68

プロビジョニングネットワークを使用する場合、クラスターノードは、ポート 67 および 68 を使用して、プロビジョニングネットワークインターフェイス経由で dnsmasq DHCP サーバーにアクセスします。

69

プロビジョニングネットワークを使用する場合、クラスターノードはプロビジョニングネットワークインターフェイスを使用してポート 69 で TFTP サーバーと通信します。TFTP サーバーはブートストラップ仮想マシン上で実行されます。ブートストラップ仮想マシンはプロビジョナーノード上で実行されます。

80

イメージキャッシュオプションを使用しない場合、または仮想メディアを使用する場合、プロビジョナーノードからクラスターノードに Red Hat Enterprise Linux CoreOS (RHCOS) イメージをストリーミングするには、プロビジョナーノードのポート 80 が baremetal マシンのネットワークインターフェイス上で開いている必要があります。

123

クラスターノードは、baremetal マシンネットワークを使用して、ポート 123 の NTP サーバーにアクセスする必要があります。

5050

Ironic Inspector API は、コントロールプレーンノード上で実行され、ポート 5050 でリッスンします。Inspector API は、ベアメタルノードのハードウェア特性に関する情報を収集するハードウェアイントロスペクションを担当します。

5051

ポート 5050 はポート 5051 をプロキシーとして使用します。

6180

仮想メディアを使用して TLS を使用せずにデプロイする場合、ワーカーノードのベースボード管理コントローラー (BMC) が RHCOS イメージにアクセスできるように、プロビジョナーノードとコントロールプレーンノードのポート 6180 は、baremetal マシンのネットワークインターフェイスで開いている必要があります。OpenShift Container Platform 4.13 以降、デフォルトの HTTP ポートは 6180 です。

6183

仮想メディアを使用して TLS でデプロイする場合、ワーカーノードの BMC が RHCOS イメージにアクセスできるように、プロビジョナーノードとコントロールプレーンノードのポート 6183 は、baremetal マシンのネットワークインターフェイスで開いている必要があります。

6385

Ironic API サーバーは、最初はブートストラップ仮想マシン上で実行され、その後はコントロールプレーンノード上で実行され、ポート 6385 でリッスンします。Ironic API を使用すると、クライアントは Ironic と対話して、新しいノードの登録、電源状態の管理、イメージのデプロイ、ハードウェアのクリーニングなどの操作を含むベアメタルノードのプロビジョニングと管理を行うことができます。

6388

ポート 6385 はポート 6388 をプロキシーとして使用します。

8080

TLS なしでイメージキャッシュを使用する場合、ポート 8080 がプロビジョナーノードで開いており、クラスターノードの BMC インターフェイスからアクセスできる必要があります。

8083

TLS ありでイメージキャッシュオプションを使用する場合、ポート 8083 がプロビジョナーノードで開いており、クラスターノードの BMC インターフェイスからアクセスできる必要があります。

9999

デフォルトでは、Ironic Python Agent (IPA) は、ポート 9999 で Ironic conductor サービスからの API 呼び出しを TCP リッスンします。IPA が実行されているベアメタルノードと Ironic conductor サービス間の通信には、このポートが使用されます。

14.2.5.2. ネットワーク MTU の増加

OpenShift Container Platform をデプロイする前に、ネットワークの最大伝送単位 (MTU) を 1500 以上に増やします。MTU が 1500 未満の場合、ノードの起動に使用される Ironic イメージが Ironic インスペクター Pod との通信に失敗し、検査が失敗する可能性があります。これが発生すると、インストールにノードを使用できないため、インストールが停止します。

14.2.5.3. NIC の設定

OpenShift Container Platform は、2 つのネットワークを使用してデプロイします。

  • provisioning: provisioning ネットワークは、OpenShift Container Platform クラスターの一部である基礎となるオペレーティングシステムを各ノードにプロビジョニングするために使用されるオプションのルーティング不可能なネットワークです。各クラスターノードの provisioning ネットワークのネットワークインターフェイスには、BIOS または UEFI が PXE ブートに設定されている必要があります。

    provisioningNetworkInterface 設定は、コントロールプレーンノード上の provisioning ネットワークの NIC 名を指定します。これは、コントロールプレーンノードと同じでなければなりません。bootMACAddress 設定は、provisioning ネットワーク用に各ノードで特定の NIC を指定する手段を提供します。

    provisioning ネットワークは任意ですが、PXE ブートには必要です。provisioning ネットワークなしでデプロイする場合、redfish-virtualmedia や idrac-virtualmedia などの仮想メディア BMC アドレス指定オプションを使用する必要があります。

  • baremetal: baremetal ネットワークはルーティング可能なネットワークです。NIC が provisioning ネットワークを使用するように設定されていない場合には、baremetal ネットワークとのインターフェイスには任意の NIC を使用することができます。
重要

VLAN を使用する場合、それぞれの NIC は、適切なネットワークに対応する別個の VLAN 上にある必要があります。

14.2.5.4. DNS 要件

クライアントは、baremetal ネットワークで OpenShift Container Platform クラスターにアクセスします。ネットワーク管理者は、正規名の拡張がクラスター名であるサブドメインまたはサブゾーンを設定する必要があります。 

<cluster_name>.<base_domain>

以下に例を示します。 

test-cluster.example.com

OpenShift Container Platform には、クラスターメンバーシップ情報を使用して A/AAAA レコードを生成する機能が含まれます。これにより、ノード名が IP アドレスに解決されます。ノードが API に登録されると、クラスターは CoreDNS-mDNS を使用せずにこれらのノード情報を分散できます。これにより、マルチキャスト DNS に関連付けられたネットワークトラフィックがなくなります。

CoreDNS を正しく機能させるには、アップストリームの DNS サーバーへの TCP 接続と UDP 接続の両方が必要です。アップストリームの DNS サーバーが OpenShift Container Platform クラスターノードから TCP 接続と UDP 接続の両方を受信できることを確認します。

OpenShift Container Platform のデプロイメントでは、以下のコンポーネントに DNS 名前解決が必要です。

  • The Kubernetes API
  • OpenShift Container Platform のアプリケーションワイルドカード Ingress API

A/AAAA レコードは名前解決に使用され、PTR レコードは逆引き名前解決に使用されます。Red Hat Enterprise Linux CoreOS (RHCOS) は、逆引きレコードまたは DHCP を使用して、すべてのノードのホスト名を設定します。

installer-provisioned installation には、クラスターメンバーシップ情報を使用して A/AAAA レコードを生成する機能が含まれています。これにより、ノード名が IP アドレスに解決されます。各レコードで、<cluster_name> はクラスター名で、<base_domain> は、install-config.yaml ファイルに指定するベースドメインです。完全な DNS レコードは <component>.<cluster_name>.<base_domain>. の形式を取ります。

表14.5 必要な DNS レコード
コンポーネントレコード説明

Kubernetes API

api.<cluster_name>.<base_domain>.

A/AAAA レコードと PTR レコード。API ロードバランサーを識別します。これらのレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。

ルート

*.apps.<cluster_name>.<base_domain>.

ワイルドカード A/AAAA レコードは、アプリケーションの Ingress ロードバランサーを参照します。アプリケーション Ingress ロードバランサーは、Ingress コントローラー Pod を実行するノードをターゲットにします。Ingress Controller Pod は、デフォルトでワーカーノードで実行されます。これらのレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。

たとえば、console-openshift-console.apps.<cluster_name>.<base_domain> は、OpenShift Container Platform コンソールへのワイルドカードルートとして使用されます。

ヒント

digコマンドを使用して、DNS 解決を確認できます。

14.2.5.5. Dynamic Host Configuration Protocol (DHCP) の要件

デフォルトでは、installer-provisioned installation は、provisioning ネットワーク用に DHCP を有効にして ironic-dnsmasq をデプロイします。provisioningNetwork 設定が、デフォルト値の managed に設定されている場合、provisioning ネットワーク上で他の DHCP サーバーを実行することはできません。provisioning ネットワーク上で DHCP サーバーを実行している場合は、install-config.yaml ファイルで provisioningNetwork 設定を unmanaged に設定する必要があります。

ネットワーク管理者は、外部 DHCP サーバー上の baremetal ネットワーク用に、OpenShift Container Platform クラスター内の各ノードの IP アドレスを予約する必要があります。

14.2.5.6. DHCP サーバーを使用するノードの IP アドレスの確保

baremetal ネットワークの場合、ネットワーク管理者は、以下を含むいくつかの IP アドレスを予約する必要があります。

  1. 2 つの一意の仮想 IP アドレス。

    • API エンドポイントの 1 つの仮想 IP アドレス。
    • ワイルドカード Ingress エンドポイントの 1 つの仮想 IP アドレス
  2. プロビジョナーノードの 1 つの IP アドレス
  3. コントロールプレーンノードごとに 1 つの IP アドレス。
  4. 各ワーカーノードの 1 つの IP アドレス (適用可能な場合)
IP アドレスの予約し、それらを静的 IP アドレスにする

一部の管理者は、各ノードの IP アドレスが DHCP サーバーがない状態で一定になるように静的 IP アドレスの使用を選択します。NMState を使用して静的 IP アドレスを設定する場合は、「OpenShift インストールの環境のセットアップ」セクションの「ホストネットワークインターフェイスの設定 (オプション)」を参照してください。

外部ロードバランサーとコントロールプレーンノード間のネットワーク

外部の負荷分散サービスとコントロールプレーンノードは同じ L2 ネットワークで実行する必要があります。また、VLAN を使用して負荷分散サービスとコントロールプレーンノード間のトラフィックをルーティングする際に同じ VLAN で実行する必要があります。

重要

ストレージインターフェイスには、DHCP 予約または静的 IP が必要です。

以下の表は、完全修飾ドメイン名の具体例を示しています。API およびネームサーバーのアドレスは、正規名の拡張で始まります。コントロールプレーンおよびワーカーノードのホスト名は例であるため、任意のホストの命名規則を使用することができます。

使用法ホスト名IP

API

api.<cluster_name>.<base_domain>

<ip>

Ingress LB (アプリケーション)

*.apps.<cluster_name>.<base_domain>

<ip>

プロビジョナーノード

provisioner.<cluster_name>.<base_domain>

<ip>

Control-plane-0

openshift-control-plane-0.<cluster_name>.<base_domain>

<ip>

Control-plane-1

openshift-control-plane-1.<cluster_name>-.<base_domain>

<ip>

Control-plane-2

openshift-control-plane-2.<cluster_name>.<base_domain>

<ip>

Worker-0

openshift-worker-0.<cluster_name>.<base_domain>

<ip>

Worker-1

openshift-worker-1.<cluster_name>.<base_domain>

<ip>

Worker-n

openshift-worker-n.<cluster_name>.<base_domain>

<ip>

注記

DHCP 予約を作成しない場合、Kubernetes API ノード、プロビジョナーノード、コントロールプレーンノード、およびワーカーノードのホスト名を設定するために、インストールプログラムで逆引き DNS 解決が必要になります。

14.2.5.7. プロビジョナーノードの要件

インストール設定でプロビジョナーノードの MAC アドレスを指定する必要があります。通常、bootMacAddress 仕様は PXE ネットワークブートに関連付けられています。ただし、Ironic プロビジョニングサービスでは、クラスターの検査中またはクラスター内のノードの再デプロイ中にノードを識別するために、bootMacAddress 仕様も必要です。

プロビジョナーノードには、ネットワークの起動、DHCP と DNS の解決、およびローカルネットワーク通信のためのレイヤー 2 接続が必要です。プロビジョナーノードには、仮想メディアの起動にレイヤー 3 接続が必要です。

14.2.5.8. ネットワークタイムプロトコル (NTP)

クラスター内の各 OpenShift Container Platform ノードは NTP サーバーにアクセスできる必要があります。OpenShift Container Platform ノードは NTP を使用してクロックを同期します。たとえば、クラスターノードは検証を必要とする SSL/TLS 証明書を使用しますが、ノード間の日付と時刻が同期していないと、検証が失敗する可能性があります。

重要

各クラスターノードの BIOS 設定で一貫性のあるクロックの日付と時刻の形式を定義してください。そうしないと、インストールが失敗する可能性があります。

切断されたクラスター上で NTP サーバーとして機能するようにコントロールプレーンノードを再設定し、コントロールプレーンノードから時間を取得するようにワーカーノードを再設定することができます。

14.2.5.9. 帯域外管理 IP アドレスのポートアクセス

帯域外管理 IP アドレスは、ノードとは別のネットワーク上にあります。インストール中に帯域外管理がプロビジョナーノードと確実に通信できるようにするには、帯域外管理 IP アドレスに、プロビジョナーノードおよび OpenShift Container Platform コントロールプレーンノード上のポート 6180 へのアクセスを許可する必要があります。TLS ポート 6183 は、たとえば Redfish などを使用する仮想メディアのインストールに必要です。

関連情報

14.2.6. ノードの設定

provisioning ネットワークを使用する場合のノードの設定

クラスター内の各ノードには、適切なインストールを行うために以下の設定が必要です。

警告

ノード間で一致していないと、インストールに失敗します。

クラスターノードには 3 つ以上の NIC を追加できますが、インストールプロセスでは最初の 2 つの NIC のみに焦点が当てられます。以下の表では、NIC1 は OpenShift Container Platform クラスターのインストールにのみ使用されるルーティング不可能なネットワーク (provisioning) です。

NICネットワークVLAN

NIC1

provisioning

<provisioning_vlan>

NIC2

baremetal

<baremetal_vlan>

プロビジョナーノードでの Red Hat Enterprise Linux (RHEL) 9.x インストールプロセスは異なる可能性があります。ローカルの Satellite サーバー、PXE サーバー、PXE 対応の NIC2 を使用して Red Hat Enterprise Linux (RHEL) 9.x をインストールする場合は、以下のようになります。

PXEブート順序

NIC1 PXE 対応の provisioning ネットワーク

1

NIC2 baremetal ネットワークPXE 対応はオプションです。

2

注記

他のすべての NIC で PXE が無効になっていることを確認します。

コントロールプレーンおよびワーカーノードを以下のように設定します。

PXEブート順序

NIC1 PXE 対応 (プロビジョニングネットワーク)

1

provisioning ネットワークを使用しないノードの設定

インストールプロセスには、1 つの NIC が必要です。

NICネットワークVLAN

NICx

baremetal

<baremetal_vlan>

NICx は、OpenShift Container Platform クラスターのインストールに使用されるルーティング可能なネットワーク (baremetal) であり、インターネットにルーティング可能です。

重要

provisioning ネットワークは任意ですが、PXE ブートには必要です。provisioning ネットワークなしでデプロイする場合、redfish-virtualmedia や idrac-virtualmedia などの仮想メディア BMC アドレス指定オプションを使用する必要があります。

手動での Secure Boot のノードの設定

Secure Boot は、ノードが UEFI ファームウェアドライバー、EFI アプリケーション、オペレーティングシステムなどの信頼できるソフトウェアのみを使用していることを確認できない場合は、ノードの起動を阻止します。

注記

Red Hat は、Redfish 仮想メディアを使用してデプロイする場合にのみ、手動で設定された Secure Boot をサポートします。

Secure Boot を手動で有効にするには、ノードのハードウェアガイドを参照し、以下を実行してください。

手順

  1. ノードを起動し、BIOS メニューを入力します。
  2. ノードのブートモードを UEFI Enabled に設定します。
  3. Secure Boot を有効にします。
重要

Red Hat は、自己生成したキーを使用する Secure Boot をサポートしません。

14.2.7. アウトオブバンド管理

ノードには通常、ベースボード管理コントローラー (BMC) が使用する追加の NIC があります。これらの BMC は provisioner ノードからアクセスできる必要があります。

各ノードは、アウトバウンド管理でアクセスできるようにする必要があります。アウトバウンド管理ネットワークを使用する場合、provisioner ノードには、OpenShift Container Platform の正常なインストールを実行するためにアウトバウンドネットワークへのアクセスが必要になります。

このアウトバウンド管理設定については、このドキュメントでは扱いません。帯域外管理に個別の管理ネットワークを使用すると、パフォーマンスが向上し、セキュリティーが向上します。ただし、provisioning ネットワークまたはベアメタルネットワークの使用は有効なオプションになります。

注記

ブートストラップ仮想マシンには、最大 2 つのネットワークインターフェイスがあります。帯域外管理用に別の管理ネットワークを設定し、プロビジョニングネットワークを使用している場合、ブートストラップ仮想マシンでは、いずれかのネットワークインターフェイスを介して管理ネットワークへのルーティングアクセスが必要になります。このシナリオでは、ブートストラップ仮想マシンは 3 つのネットワークにアクセスできます。

  • ベアメタルネットワーク
  • プロビジョニングネットワーク
  • 管理インターフェイスの 1 つを介してルーティングされる管理ネットワーク

14.2.8. インストールに必要なデータ

OpenShift Container Platform クラスターのインストール前に、すべてのクラスターノードから以下の情報を収集します。

  • アウトバウンド管理 IP

    • 例

      • Dell (iDRAC) IP
      • HP (iLO) IP
      • Fujitsu (iRMC) IP

provisioning ネットワークを使用する場合

  • NIC (provisioning) MAC アドレス
  • NIC (baremetal) MAC アドレス

provisioning ネットワークを省略する場合

  • NIC (baremetal) MAC アドレス

14.2.9. ノードの検証チェックリスト

provisioning ネットワークを使用する場合

  • ❏ NIC1 VLAN が provisioning ネットワークについて設定されている。
  • ❏ provisioning ネットワークの NIC1 は、プロビジョナー、コントロールプレーン、およびワーカーノードで PXE 対応として使用できる。
  • ❏ NIC2 VLAN が baremetal ネットワークについて設定されている。
  • ❏ PXE が他のすべての NIC で無効にされている。
  • ❏ DNS は API および Ingress エンドポイントで設定されている。
  • ❏ コントロールプレーンおよびワーカーノードが設定されている。
  • ❏ すべてのノードがアウトオブバンド管理でアクセス可能である。
  • ❏ (オプション) 別個の管理ネットワークが作成されている。
  • ❏ インストールに必要なデータ。

provisioning ネットワークを省略する場合

  • ❏ NIC1 VLAN が baremetal ネットワークについて設定されている。
  • ❏ DNS は API および Ingress エンドポイントで設定されている。
  • ❏ コントロールプレーンおよびワーカーノードが設定されている。
  • ❏ すべてのノードがアウトオブバンド管理でアクセス可能である。
  • ❏ (オプション) 別個の管理ネットワークが作成されている。
  • ❏ インストールに必要なデータ。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.