8.2. 前提条件

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

1 つの Red Hat Enterprise Linux (RHEL) 8.x がインストールされているプロビジョナーノード。
3 つのコントロールプレーンノード
ベースボード管理コントローラー (BMC) の各ノードへのアクセス。
1 つ以上のネットワーク:
1. 1 つの必須のルーティング可能なネットワーク
2. 1 つのオプションのノードのプロビジョニング用のネットワーク
3. 1 つのオプションの管理ネットワーク

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

8.2.1. ノードの要件

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

CPU アーキテクチャー: すべてのノードで x86_64 CPU アーキテクチャーを使用する必要があります。
同様のノード: Red Hat では、ノードにロールごとに同じ設定を指定することを推奨しています。つまり Red Hat では、同じ CPU、メモリー、ストレージ設定の同じブランドおよびモデルのノードを使用することを推奨しています。
ベースボード管理コントローラー: provisioner ノードは、各 OpenShift Container Platform クラスターノードのベースボード管理コントローラー (BMC) にアクセスできる必要があります。IPMI、RedFish、または独自のプロトコルを使用できます。
最新の生成: ノードは最新の生成されたノードである必要があります。インストーラーでプロビジョニングされるインストールは BMC プロトコルに依存するため、ハードウェアは IPMI 暗号化スイート 17 をサポートしている必要があります。また、RHEL 8 は RAID コントローラーの最新のドライバーが同梱されています。ノードは provisioner ノード用に RHEL 8 を、コントローラープレーンおよびワーカーノード用に RHCOS 8 をサポートするのに必要な新しいバージョンのノードであることを確認します。
レジストリーノード: (オプション) 非接続のミラーリングされていないレジストリーを設定する場合、レジストリーは独自のノードに置くことが推奨されます。
プロビジョナーノード: インストーラーでプロビジョニングされるインストールには 1 つの provisioner ノードが必要です。
コントロールプレーン: インストーラーでプロビジョニングされるインストールには、高可用性を実現するために 3 つのコントロールプレーンノードが必要です。
ワーカーノード: 必須ではありませんが、一般的な実稼働クラスターには 1 つまたは複数のワーカーノードがあります。小規模なクラスターでは、開発、実稼働およびテスト時の管理者および開発者に対するリソース効率が高くなります。
ネットワークインターフェイス: 各ノードでは、ルーティング可能な baremetal ネットワークに 1 つ以上のネットワークインターフェイスが必要です。デプロイメントに provisioning ネットワークを使用する場合、各ノードに provisioning ネットワーク用に 1 つのネットワークインターフェイスが必要になります。provisioning ネットワークの使用はデフォルト設定です。ネットワークインターフェイスの命名は、プロビジョニングネットワーク用のコントロールプレーンノード全体で一貫している必要があります。たとえば、コントロールプレーンノードがプロビジョニングネットワークに eth0 NIC を使用する場合は、他のコントロールプレーンノードもこれを使用する必要があります。
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 を使用して OpenShift Container Platform クラスターをデプロイするには、UEFI ブートモードおよび Secure Boot を各コントロールプレーンノードおよび各ワーカーノードで有効にする必要があります。Red Hat は、インストーラーでプロビジョニングされるインストールで Red Hat Fish 仮想メディアを使用している場合に限り、Secure Boot をサポートします。Red Hat は、自己生成したキーを使用する Secure Boot をサポートしません。

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

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

表8.1 Redfish 仮想メディアのファームウェアの互換性
ハードウェア	モデル	管理	ファームウェアバージョン
HP	第 10 世代	iLO5	該当なし
Dell	第 14 世代	iDRAC 9	v4.20.20.20 - 04.40.00.00
Dell	第 13 世代	iDRAC 8	v2.75.75.75+

注記

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

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

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

重要

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

8.2.3. ネットワーク要件

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

8.2.3.1. NIC の設定

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

provisioning: provisioning ネットワークは OpenShift Container Platform クラスターの一部である基礎となるオペレーティングシステムを各ノードにプロビジョニングするために使用される オプションの ルーティング不可能なネットワークです。provisioning ネットワークを使用してデプロイする場合、各ノードの最初の NIC ( eth0 または eno1 など) は、provisioning ネットワークと対話する 必要があります。
baremetal: baremetal ネットワークはルーティング可能なネットワークです。provisioning ネットワークを使用してデプロイする場合、各ノードの 2 つ目の NIC ( eth1 または eno2 など) は、baremetal ネットワークと対話する 必要があります。provisioning ネットワークなしでデプロイする場合、baremetal ネットワークと対話するために各ノードで任意の NIC を使用することができます。

重要

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

8.2.3.2. DNS サーバーの設定

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

<cluster_name>.<domain-name>

以下に例を示します。

test-cluster.example.com

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

8.2.3.3. 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 アドレスを予約する必要があります。

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

baremetal ネットワークの場合、ネットワーク管理者は、デプロイメント後に変更されないように、複数の IP アドレスを予約する必要があります。以下に例を示します。

2 つの仮想 IP アドレス
- API エンドポイントの 1 つの IP アドレス
- ワイルドカード Ingress エンドポイントの 1 つの IP アドレス
プロビジョナーノードの 1 つの IP アドレス
各コントロールプレーン (マスター) ノード 1 つの IP アドレス
各ワーカーノードの 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 を使用します。

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

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

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

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

使用法	ホスト名	IP
API	api.<cluster_name>.<domain>	<ip>
Ingress LB (アプリケーション)	*.apps.<cluster_name>.<domain>	<ip>
プロビジョナーノード	provisioner.<cluster_name>.<domain>	<ip>
Master-0	openshift-master-0.<cluster_name>.<domain>	<ip>
Master-1	openshift-master-1.<cluster_name>.<domain>	<ip>
Master-2	openshift-master-2.<cluster_name>.<domain>	<ip>
Worker-0	openshift-worker-0.<cluster_name>.<domain>	<ip>
Worker-1	openshift-worker-1.<cluster_name>.<domain>	<ip>
Worker-n	openshift-worker-n.<cluster_name>.<domain>	<ip>

8.2.3.5. Network Time Protocol (NTP)

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

重要

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

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

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

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

注記

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

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

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

帯域外管理 IP アドレスは、ノードとは別のネットワーク上にあります。インストール中に帯域外管理がベアメタルノードと通信できるようにするには、帯域外管理 IP アドレスアドレスに TCP6180 ポートへのアクセスを許可する必要があります。

8.2.4. ノードの設定

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

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

警告

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

クラスターノードには 3 つ以上の NIC を追加できますが、インストールプロセスでは最初の 2 つの NIC のみに焦点が当てられます。

NIC	ネットワーク Network	VLAN
NIC1	`provisioning`	<provisioning-vlan>
NIC2	`baremetal`	<baremetal-vlan>

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

プロビジョナーノードでの 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	ネットワーク Network	VLAN
NICx	`baremetal`	<baremetal-vlan>

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

ノードでの Secure Boot の設定

Secure Boot は、ノードが UEFI ファームウェアドライバー、EFI アプリケーション、オペレーティングシステムなどの信頼できるソフトウェアのみを使用していることを検証できない場合、ノードの起動を防ぎます。Red Hat は、RedFish 仮想メディアを使用してデプロイする場合にのみ Secure Boot をサポートします。

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

ノードを起動し、BIOS メニューを入力します。
ノードのブートモードを UEFI Enabled に設定します。
Secure Boot を有効にします。
重要
Red Hat は、自己生成したキーを使用する Secure Boot をサポートしません。

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

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

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

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

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

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

アウトバウンド管理 IP
- 例
  - Dell (iDRAC) IP
  - HP (iLO) IP
  - Fujitsu (iRMC) IP

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

NIC1 (provisioning) MAC アドレス
NIC2 (baremetal) MAC アドレス

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

NICx (baremetal) MAC アドレス

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