13.2. 前提条件
OpenShift Container Platform のインストーラーでプロビジョニングされるインストールには、以下が必要です。
- 1 つの Red Hat Enterprise Linux (RHEL) 8.x がインストールされているプロビジョナーノード。プロビジョナーは、インストール後に削除できます。
- 3 つのコントロールプレーンノード
- ベースボード管理コントローラー (BMC) の各ノードへのアクセス。
1 つ以上のネットワーク:
- 1 つの必須 のルーティング可能なネットワーク
- 1 つのオプションのプロビジョニングネットワーク
- 1 つのオプションの管理ネットワーク
OpenShift Container Platform のインストーラーでプロビジョニングされるインストールを開始する前に、ハードウェア環境が以下の要件を満たしていることを確認してください。
13.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 を使用してデプロイすることができます。
- 手動: 手動で Secure Boot を使用して OpenShift Container Platform クラスターをデプロイするには、UEFI ブートモードおよび Secure Boot を各コントロールプレーンノードおよび各ワーカーノードで有効にする必要があります。Red Hat は、インストーラーでプロビジョニングされるインストールで Redfish 仮想メディアを使用している場合にのみ、手動で有効にした UEFI および Secure Boot で、Secure Boot をサポートします。詳細は、ノードの設定セクションの手動での Secure Boot のノードの設定を参照してください。
マネージド: マネージド 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 をサポートしません。
13.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 でサポートされていることを確認してください。
13.2.3. 仮想メディアを使用したインストールのファームウェア要件
インストーラーでプロビジョニングされる OpenShift Container Platform クラスターのインストールプログラムは、Redfish 仮想メディアとのハードウェアおよびファームウェアの互換性を検証します。ノードファームウェアに互換性がない場合、インストールプログラムはノードへのインストールを開始しません。以下の表は、Redfish 仮想メディアを使用してデプロイされるインストーラーでプロビジョニングされる OpenShift Container Platform クラスターで機能するようにテストおよび検証された最小ファームウェアバージョンの一覧です。
Red Hat は、ファームウェア、ハードウェア、またはその他のサードパーティーコンポーネントの組み合わせをすべてテストしません。サードパーティーサポートの詳細は、Red Hat サードパーティーサポートポリシー を参照してください。ファームウェアの更新については、ノードのハードウェアドキュメントを参照するか、ハードウェアベンダーにお問い合わせください。
モデル | 管理 | ファームウェアのバージョン |
---|---|---|
第 10 世代 | iLO5 | 2.63 以降 |
モデル | 管理 | ファームウェアのバージョン |
---|---|---|
第 15 世代 | iDRAC 9 | v5.10.00.00 - v5.10.50.00 のみ |
第 14 世代 | iDRAC 9 | v5.10.00.00 - v5.10.50.00 のみ |
第 13 世代 | iDRAC 8 | v2.75.75.75 以降 |
Dell サーバーの場合、OpenShift Container Platform クラスターノードについて、iDRAC コンソールで AutoAttach が有効にされていることを確認します。メニューパスは以下のようになります。Configuration 04.40.00.00
と 5.xx
シリーズを含むすべてのリリースの場合、仮想コンソールプラグインは HTML5 の拡張バージョンである eHTML5 にデフォルト設定され、InsertVirtualMedia ワークフローで問題が発生します。この問題を回避するには、HTML5 を使用するようにプラグインを設定します。メニューパスは以下の通りです。Configuration
13.2.4. ネットワーク要件
OpenShift Container Platform のインストーラーでプロビジョニングされるインストールには、複数のネットワーク要件があります。まず、インストーラーでプロビジョニングされるインストールでは、各ベアメタルノードにオペレーティングシステムをプロビジョニングするためのルーティング不可能な provisioning
ネットワークをオプションで使用します。次に、インストーラーでプロビジョニングされるインストールでは、ルーティング可能な baremetal
ネットワークを使用します。
![インストーラーがプロビジョニングしたネットワーク](https://access.redhat.com/webassets/avalon/d/OpenShift_Container_Platform-4.10-Installing-ja-JP/images/8c83198a4fe67a6610c9310ce71c7f5b/210_OpenShift_Baremetal_IPI_Deployment_updates_0122_2.png)
13.2.4.1. ネットワーク MTU の増加
OpenShift Container Platform をデプロイする前に、ネットワークの最大伝送単位 (MTU) を 1500 以上に増やします。MTU が 1500 未満の場合、ノードの起動に使用される Ironic イメージが Ironic インスペクター Pod との通信に失敗し、検査が失敗する可能性があります。これが発生すると、インストールにノードを使用できないため、インストールが停止します。
13.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-virtualmedia
やidrac-virtualmedia
などの仮想メディア BMC アドレス指定オプションを使用する必要があります。-
baremetal
:baremetal
ネットワークはルーティング可能なネットワークです。NIC がprovisioning
ネットワークを使用するように設定されていない場合には、baremetal
ネットワークとのインターフェイスには任意の NIC を使用することができます。
VLAN を使用する場合、それぞれの NIC は、適切なネットワークに対応する別個の VLAN 上にある必要があります。
13.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>.
の形式を取ります。
コンポーネント | レコード | 説明 |
---|---|---|
Kubernetes API |
| A/AAAA レコードと PTR レコード。API ロードバランサーを識別します。これらのレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。 |
ルート |
| ワイルドカード A/AAAA レコードは、アプリケーションの Ingress ロードバランサーを参照します。アプリケーション Ingress ロードバランサーは、Ingress コントローラー Pod を実行するノードをターゲットにします。Ingress Controller Pod は、デフォルトでワーカーノードで実行されます。これらのレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。
たとえば、 |
dig
コマンドを使用して、DNS 解決を確認できます。
13.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 アドレスを予約する必要があります。
13.2.4.5. DHCP サーバーを使用するノードの IP アドレスの確保
baremetal
ネットワークの場合、ネットワーク管理者は以下を含む多数の IP アドレスを予約する必要があります。
2 つの一意の仮想 IP アドレス。
- API エンドポイントの 1 つの仮想 IP アドレス。
- ワイルドカード Ingress エンドポイントの 1 つの仮想 IP アドレス
- プロビジョナーノードの 1 つの IP アドレス
- コントロールプレーンノードごとに 1 つの IP アドレス。
- 各ワーカーノードの 1 つの IP アドレス (適用可能な場合)
一部の管理者は、各ノードの IP アドレスが DHCP サーバーがない状態で一定になるように静的 IP アドレスの使用を選択します。NMState を使用して静的 IP アドレスを設定するには、OpenShift インストールの環境のセットアップセクションの(オプション) ホストネットワークインターフェイスの設定を参照してください。
外部の負荷分散サービスとコントロールプレーンノードは同じ L2 ネットワークで実行する必要があります。また、VLAN を使用して負荷分散サービスとコントロールプレーンノード間のトラフィックをルーティングする際に同じ VLAN で実行する必要があります。
ストレージインターフェイスには、DHCP 予約または静的 IP が必要です。
以下の表は、完全修飾ドメイン名の具体例を示しています。API および Nameserver アドレスは、正式名の拡張子で始まります。コントロールプレーンおよびワーカーノードのホスト名は例であるため、任意のホストの命名規則を使用することができます。
使用法 | ホスト名 | IP |
---|---|---|
API |
|
|
Ingress LB (アプリケーション) |
|
|
プロビジョナーノード |
|
|
Control-plane-0 |
|
|
Control-plane-1 |
|
|
Control-plane-2 |
|
|
Worker-0 |
|
|
Worker-1 |
|
|
Worker-n |
|
|
DHCP 予約を作成しない場合には、インストーラーは、Kubernetes API ノード、プロビジョナーノード、コントロールプレーンノード、およびワーカーノードのホスト名を設定するために逆引き DNS 解決を必要とします。
13.2.4.6. ネットワークタイムプロトコル (NTP)
クラスター内の各 OpenShift Container Platform ノードは NTP サーバーにアクセスできる必要があります。OpenShift Container Platform ノードは NTP を使用してクロックを同期します。たとえば、クラスターノードは、検証を必要とする SSL 証明書を使用します。これは、ノード間の日付と時刻が同期していない場合に失敗する可能性があります。
各クラスターノードの BIOS 設定で一貫性のあるクロックの日付と時刻の形式を定義してください。そうしないと、インストールが失敗する可能性があります。
切断されたクラスター上で NTP サーバーとして機能するようにコントロールプレーンノードを再設定し、コントロールプレーンノードから時間を取得するようにワーカーノードを再設定することができます。
13.2.4.7. 帯域外管理 IP アドレスのポートアクセス
帯域外管理 IP アドレスは、ノードとは別のネットワーク上にあります。インストール中に帯域外管理がプロビジョナーと確実に通信できるようにするには、帯域外管理 IP アドレスに、ブートストラップホストのポート 80
および OpenShift Container Platform コントロールプレーンホストのポート 6180
へのアクセスを許可する必要があります。Redfish などを介した仮想メディアのインストールには、TLS ポート 6183
が必要です。
13.2.5. ノードの設定
provisioning
ネットワークを使用する場合のノードの設定
クラスター内の各ノードには、適切なインストールを行うために以下の設定が必要です。
ノード間で一致していないと、インストールに失敗します。
クラスターノードには 3 つ以上の NIC を追加できますが、インストールプロセスでは最初の 2 つの NIC のみに焦点が当てられます。以下の表では、NIC1 は OpenShift Container Platform クラスターのインストールにのみ使用されるルーティング不可能なネットワーク (provisioning
) です。
NIC | ネットワーク | VLAN |
---|---|---|
NIC1 |
|
|
NIC2 |
|
|
プロビジョナーノードでの Red Hat Enterprise Linux (RHEL) 8.x インストールプロセスは異なる可能性があります。ローカルの Satellite サーバー、PXE サーバー、PXE 対応の NIC2 を使用して Red Hat Enterprise Linux (RHEL) 8.x をインストールするには、以下のようになります。
PXE | ブート順序 |
---|---|
NIC1 PXE 対応の | 1 |
NIC2 | 2 |
他のすべての NIC で PXE が無効になっていることを確認します。
コントロールプレーンおよびワーカーノードを以下のように設定します。
PXE | ブート順序 |
---|---|
NIC1 PXE 対応 (プロビジョニングネットワーク) | 1 |
provisioning
ネットワークを使用しないノードの設定
インストールプロセスには、1 つの NIC が必要です。
NIC | ネットワーク | VLAN |
---|---|---|
NICx |
|
|
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 を手動で有効にするには、ノードのハードウェアガイドを参照し、以下を実行してください。
手順
- ノードを起動し、BIOS メニューを入力します。
-
ノードのブートモードを
UEFI Enabled
に設定します。 - Secure Boot を有効にします。
Red Hat は、自己生成したキーを使用する Secure Boot をサポートしません。
Fujitsu iRMC の互換性サポートモジュールの設定
互換性サポートモジュール (CSM) 設定は、UEFI システムとのレガシー BIOS 後方互換性をサポートします。Fujitsu iRMC を使用してクラスターをデプロイする場合は、CSM を設定する必要があります。そうしないと、インストールが失敗する可能性があります。
特定のノードタイプの CSM の設定については、ノードのハードウェアガイドを参照してください。
前提条件
-
セキュアブートコントロールを無効化したことを確認する。Security
Secure Boot Configuration Secure Boot Control で、この機能を無効化できます。
手順
- ノードを起動し、BIOS メニューを選択します。
- Advanced タブで、リストから CSM Configuration を選択します。
Launch CSM オプションを有効にして、次の値を設定します。
項目 値 起動オプションフィルター
UEFI およびレガシー
Launch PXE OpROM Policy
UEFI のみ
ストレージ OpROM ポリシーの起動
UEFI のみ
その他の PCI デバイス ROM の優先順位
UEFI のみ
13.2.6. アウトオブバンド管理 (Out-of-band Management: 帯域外管理)
ノードには通常、ベースボード管理コントローラー (BMC) が使用する追加の NIC があります。これらの BMC は provisioner ノードからアクセスできる必要があります。
各ノードは、アウトバウンド管理でアクセスできるようにする必要があります。アウトバウンド管理ネットワークを使用する場合、 provisioner ノードには、OpenShift Container Platform の正常なインストールを実行するためにアウトバウンドネットワークへのアクセスが必要になります。
このアウトバウンド管理設定については、本書では扱いません。帯域外管理に個別の管理ネットワークを使用すると、パフォーマンスが向上し、セキュリティーが向上します。ただし、provisioning ネットワークまたはベアメタルネットワークの使用は有効なオプションになります。
ブートストラップ仮想マシンには、最大 2 つのネットワークインターフェイスがあります。帯域外管理用に別の管理ネットワークを設定し、プロビジョニングネットワークを使用している場合、ブートストラップ仮想マシンでは、いずれかのネットワークインターフェイスを介して管理ネットワークへのルーティングアクセスが必要になります。このシナリオでは、ブートストラップ仮想マシンは 3 つのネットワークにアクセスできます。
- ベアメタルネットワーク
- プロビジョニングネットワーク
- 管理インターフェイスの 1 つを介してルーティングされる管理ネットワーク
13.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 アドレス
13.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: 帯域外管理) でアクセス可能である。
- ❏ (オプション) 別個の管理ネットワークが作成されている。
- ❏ インストールに必要なデータ。