10.2. 前提条件


OpenShift Container Platform のインストーラーでプロビジョニングされるインストールには、以下が必要です。

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

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

OpenShift Container Platform のインストーラーでプロビジョニングされるインストールを開始する前に、ハードウェア環境が以下の要件を満たしていることを確認してください。

10.2.1. ノードの要件

インストーラーでプロビジョニングされるインストールには、ハードウェアノードの各種の要件があります。

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

    重要

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

  • ネットワークインターフェイス: 各ノードでは、ルーティング可能な baremetal ネットワークに 1 つ以上のネットワークインターフェイスが必要です。デプロイメントに provisioning ネットワークを使用する場合、各ノードに provisioning ネットワーク用に 1 つのネットワークインターフェイスが必要になります。provisioning ネットワークの使用はデフォルト設定です。
  • Unified Extensible Firmware Interface (UEFI): インストーラーでプロビジョニングされるインストールでは、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 は、インストーラーでプロビジョニングされるインストールで 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 を使用したインストーラーでプロビジョニングされるインストールのみをサポートします。管理対象 Secure Boot を使用したデプロイには、Redfish 仮想メディアは必要ありません。詳細は、OpenShift インストールの環境のセットアップセクションの管理対象 Secure Boot の設定を参照してください。

      注記

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

10.2.2. 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 でサポートされていることを確認してください。

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

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

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

HP

第 10 世代

iLO5

2.63 以降

Dell

第 14 世代

iDRAC 9

v4.20.20.20 - v4.40.00.00 のみ

第 13 世代

iDRAC 8

v2.75.75.75 以降

注記

Red Hat は、ファームウェア、ハードウェア、またはその他のサードパーティーコンポーネントの組み合わせをすべてテストしません。サードパーティーサポートの詳細は、Red Hat サードパーティーサポートポリシー を参照してください。

ファームウェアの更新については、ノードのハードウェアドキュメントを参照するか、ハードウェアベンダーにお問い合わせください。

HP サーバーの場合、Ironic は、仮想メディアで iLO4 をサポートしないので、Redfish 仮想メディアは、iLO4 を実行する第 9 世代のシステムではサポートされません。

Dell サーバーの場合、OpenShift Container Platform クラスターノードについて、iDRAC コンソールで AutoAttach が有効にされていることを確認します。メニューパスは以下のようになります。Configuration Virtual Media Attach Mode AutoAttachiDRAC 9 ファームウェアバージョン 04.40.00.00 では、仮想コンソールプラグインがデフォルトで eHTML5 になり、InsertVirtualMedia ワークフローで問題が発生します。この問題を回避するには、プラグインを HTML5 に設定します。メニューパスは以下の通りです。Configuration Virtual console Plug-in Type HTML5

重要

インストーラーは、仮想メディアを使用したインストール時にノードのファームウェアが上記のバージョンよりも古いバージョンの場合にノードでインストールを開始しません。

10.2.4. ネットワーク要件

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

インストーラーがプロビジョニングしたネットワーク

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

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

10.2.4.2. NIC の設定

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

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

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

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

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

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

10.2.4.3. DNS 要件

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

<cluster_name>.<base_domain>

以下に例を示します。

test-cluster.example.com

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

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

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

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

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

表10.2 必要な 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 解決を確認できます。

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

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

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

10.2.4.5. 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 アドレスの使用を選択します。OpenShift Container Platform クラスターで静的 IP アドレスを使用するには、IP アドレスを無限リースで予約します。デプロイメント時に、インストーラーは DHCP で割り当てられたアドレスから静的 IP アドレスに NIC を再設定します。無限ではない DHCP リースを持つ NIC は、DHCP を使用するように設定された状態になります。

IP アドレスを無限リースで設定することは、Machine Config Operator を使用してデプロイされるネットワーク設定と互換性がありません。

DHCP サーバーで無限のリースを提供できることの確認

rfc2131 で指定されているように無限リースを適切に設定するには、DHCP サーバーでの DHCP 有効期限を 4294967295 秒に指定する必要があります。DHCP の無限リース時間に返された値がそれよりも小さい値であった場合には、ノードはエラーを報告し、ノードに永続的な IP は設定されません。RHEL 8 では dhcpd は無限のリースが提供されません。プロビジョナーノードを使用して、リース時間が無限の動的 IP アドレスを提供する場合は、 dhcpd ではなく dnsmasq を使用します。

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

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

デプロイ後に IP アドレスを手動で変更しないでください。

デプロイメント後にワーカーノードの IP アドレスを手動で変更しないでください。デプロイメント後にワーカーノードの IP アドレスを変更するには、ワーカーノードがスケジュール対象外としてマークし、Pod を退避してノードを削除し、これを新規 IP アドレスで再作成する必要があります。詳細は、ノードの操作を参照してください。デプロイメント後にコントロールプレーンノードの IP アドレスを変更するには、サポートにお問い合わせください。

ストレージインターフェイスには DHCP 予約が必要です。

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

使用法ホスト名IP

API

api.<cluster_name>.<base_domain>

<ip>

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

*.apps.<cluster_name>.<base_domain>

<ip>

プロビジョナーノード

provisioner.<cluster_name>.<base_domain>

<ip>

Master-0

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

<ip>

Master-1

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

<ip>

Master-2

openshift-master-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 解決を必要とします。

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

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

重要

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

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

10.2.4.7. ステートドリブンのネットワーク設定要件 (テクノロジープレビュー)

OpenShift Container Platform は、 kubernetes-nmstate を使用し、クラスターノードのセカンダリーネットワークインターフェイスで、インストール後の追加のステートドリブンのネットワーク設定をサポートします。たとえば、システム管理者は、ストレージネットワークのインストール後に、クラスターノードにセカンダリーネットワークインターフェイスを設定することができます。

注記

設定は、Pod のスケジュール前に行われる必要があります。

ステートドリブンのネットワーク設定では、kubernetes-nmstate をインストールする必要があり、クラスターノード上で Network Manager を実行する必要もあります。詳細は、OpenShift Virtualization > Kubernetes NMState (テクノロジープレビュー) を参照してください。

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

帯域外管理 IP アドレスは、ノードとは別のネットワーク上にあります。インストール中に帯域外管理がプロビジョニングノードと確実に通信できるようにするには、帯域外管理 IP アドレスに、ブートストラップホストのポート 80 および OpenShift Container Platform コントロールプレーンホストのポート 6180 へのアクセスを許可する必要があります。

10.2.5. ノードの設定

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) 8.x インストールプロセスは異なる可能性があります。ローカルの Satellite サーバー、PXE サーバー、PXE 対応の NIC2 を使用して Red Hat Enterprise Linux (RHEL) 8.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-virtualmediaidrac-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 をサポートしません。

Fujitsu iRMC の互換性サポートモジュールの設定

互換性サポートモジュール (CSM) 設定は、UEFI システムとのレガシー BIOS 後方互換性をサポートします。Fujitsu iRMC を使用してクラスターをデプロイする場合は、CSM を設定する必要があります。そうしないと、インストールが失敗する可能性があります。

注記

特定のノードタイプの CSM の設定については、ノードのハードウェアガイドを参照してください。

前提条件

  • セキュアブートコントロールを無効化したことを確認する。Security Secure Boot Configuration Secure Boot Control で、この機能を無効化できます。

手順

  1. ノードを起動し、BIOS メニューを選択します。
  2. Advanced タブで、リストから CSM Configuration を選択します。
  3. Launch CSM オプションを有効にして、次の値を設定します。

    項目

    起動オプションフィルター

    UEFI およびレガシー

    Launch PXE OpROM Policy

    UEFI のみ

    ストレージ OpROM ポリシーの起動

    UEFI のみ

    その他の PCI デバイス ROM の優先順位

    UEFI のみ

10.2.6. アウトオブバンド管理 (Out-of-band Management: 帯域外管理)

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

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

このアウトバウンド管理設定については、本書では扱いません。アウトバウンド管理には、別個の管理ネットワークを設定することを推奨します。ただし、provisioning ネットワークまたは baremetal ネットワークの使用は有効なオプションになります。

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

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

  • アウトバウンド管理 IP

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

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

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

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

  • NIC (baremetal) MAC アドレス

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

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

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

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

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

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.