Red Hat Summit2.5. ネットワーク要件
OpenShift Container Platform の installer-provisioned installation には、複数のネットワーク要件があります。まず、installer-provisioned installation では、各ベアメタルノードにオペレーティングシステムをプロビジョニングするためのルーティング不可能な provisioning ネットワークをオプションで使用します。次に、installer-provisioned installation では、ルーティング可能な baremetal ネットワークを使用します。
2.5.1. 必須ポートが開いていることを確認する
クラスター間で特定のノードが開いてなければ、installer-provisioned によるインストールは正常に完了しません。ファーエッジワーカーノードに別のサブネットを使用する場合などの特定の状況では、これらのサブネット内のノードが、次の必須ポートで他のサブネット内のノードと通信できることを確認する必要があります。
| ポート | 説明 |
|---|---|
|
|
プロビジョニングネットワークを使用する場合、クラスターノードは、ポート |
|
|
プロビジョニングネットワークを使用する場合、クラスターノードはプロビジョニングネットワークインターフェイスを使用してポート |
|
|
イメージキャッシュオプションを使用しない場合、または仮想メディアを使用する場合、プロビジョナーノードからクラスターノードに Red Hat Enterprise Linux CoreOS (RHCOS) イメージをストリーミングするには、プロビジョナーノードのポート |
|
|
クラスターノードは、 |
|
|
Ironic Inspector API は、コントロールプレーンノード上で実行され、ポート |
|
|
ポート |
|
|
仮想メディアを使用して TLS を使用せずにデプロイする場合、ワーカーノードのベースボード管理コントローラー (BMC) が RHCOS イメージにアクセスできるように、プロビジョナーノードとコントロールプレーンノードのポート |
|
|
仮想メディアを使用して TLS でデプロイする場合、ワーカーノードの BMC が RHCOS イメージにアクセスできるように、プロビジョナーノードとコントロールプレーンノードのポート |
|
|
Ironic API サーバーは、最初はブートストラップ仮想マシン上で実行され、その後はコントロールプレーンノード上で実行され、ポート |
|
|
ポート |
|
|
TLS なしでイメージキャッシュを使用する場合、ポート |
|
|
TLS ありでイメージキャッシュオプションを使用する場合、ポート |
|
|
デフォルトでは、Ironic Python Agent (IPA) は、ポート |
2.5.2. ネットワーク MTU の増加
OpenShift Container Platform をデプロイする前に、ネットワークの最大伝送単位 (MTU) を 1500 以上に増やします。MTU が 1500 未満の場合、ノードの起動に使用される Ironic イメージが Ironic インスペクター Pod との通信に失敗し、検査が失敗する可能性があります。これが発生すると、インストールにノードを使用できないため、インストールが停止します。
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 上にある必要があります。
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>. の形式を取ります。
| コンポーネント | レコード | 説明 |
|---|---|---|
| Kubernetes API |
| A/AAAA レコードと PTR レコード。API ロードバランサーを識別します。これらのレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。 |
| ルート |
| ワイルドカード A/AAAA レコードは、アプリケーションの Ingress ロードバランサーを参照します。アプリケーション Ingress ロードバランサーは、Ingress コントローラー Pod を実行するノードをターゲットにします。Ingress Controller Pod は、デフォルトでワーカーノードで実行されます。これらのレコードは、クラスター外のクライアントおよびクラスター内のすべてのノードで解決できる必要があります。
たとえば、 |
digコマンドを使用して、DNS 解決を確認できます。
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 アドレスを予約する必要があります。
2.5.6. 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 およびネームサーバーのアドレスは、正規名の拡張で始まります。コントロールプレーンおよびワーカーノードのホスト名は例であるため、任意のホストの命名規則を使用することができます。
| 使用法 | ホスト名 | IP |
|---|---|---|
| API |
|
|
| Ingress LB (アプリケーション) |
|
|
| プロビジョナーノード |
|
|
| Control-plane-0 |
|
|
| Control-plane-1 |
|
|
| Control-plane-2 |
|
|
| Worker-0 |
|
|
| Worker-1 |
|
|
| Worker-n |
|
|
DHCP 予約を作成しない場合、Kubernetes API ノード、プロビジョナーノード、コントロールプレーンノード、およびワーカーノードのホスト名を設定するために、インストールプログラムで逆引き DNS 解決が必要になります。
2.5.7. プロビジョナーノードの要件
インストール設定でプロビジョナーノードの MAC アドレスを指定する必要があります。通常、bootMacAddress 仕様は PXE ネットワークブートに関連付けられています。ただし、Ironic プロビジョニングサービスでは、クラスターの検査中またはクラスター内のノードの再デプロイ中にノードを識別するために、bootMacAddress 仕様も必要です。
プロビジョナーノードには、ネットワークの起動、DHCP と DNS の解決、およびローカルネットワーク通信のためのレイヤー 2 接続が必要です。プロビジョナーノードには、仮想メディアの起動にレイヤー 3 接続が必要です。
2.5.8. ネットワークタイムプロトコル (NTP)
クラスター内の各 OpenShift Container Platform ノードは NTP サーバーにアクセスできる必要があります。OpenShift Container Platform ノードは NTP を使用してクロックを同期します。たとえば、クラスターノードは検証を必要とする SSL/TLS 証明書を使用しますが、ノード間の日付と時刻が同期していないと、検証が失敗する可能性があります。
各クラスターノードの BIOS 設定で一貫性のあるクロックの日付と時刻の形式を定義してください。そうしないと、インストールが失敗する可能性があります。
切断されたクラスター上で NTP サーバーとして機能するようにコントロールプレーンノードを再設定し、コントロールプレーンノードから時間を取得するようにワーカーノードを再設定することができます。
2.5.9. 帯域外管理 IP アドレスのポートアクセス
帯域外管理 IP アドレスは、ノードとは別のネットワーク上にあります。インストール中に帯域外管理がプロビジョナーノードと確実に通信できるようにするには、帯域外管理 IP アドレスに、プロビジョナーノードおよび OpenShift Container Platform コントロールプレーンノード上のポート 6180 へのアクセスを許可する必要があります。TLS ポート 6183 は、たとえば Redfish などを使用する仮想メディアのインストールに必要です。
