ホストされたコントロール プレーンを使用したAzure Red Hat OpenShift用にクラスター ネットワークを計画する (プレビュー)

ホストされたコントロール プレーンを使用するAzure Red Hat OpenShiftは、ワーカー ノードをAzure仮想ネットワークにデプロイし、専用サブネットを使用して、ホストされたコントロール プレーンとワーカー ノードの間にプライベート接続を確立します。 クラスターを作成する前に、仮想ネットワークのレイアウト、サブネット、IP アドレス範囲を計画する必要があります。

コンピューティング容量を計画する

ノード プールはコンピューティング容量を提供します。 ノード プールは、同じ VM サイズ、ディスク構成、および可用性ゾーンを共有するワーカー ノードのグループです。 1 つのクラスターに複数のノード プールを作成して、異なるハードウェアで異なるワークロードの種類を実行できます。 サポートされているワーカー ノード VM のサイズについては、「 サポートされている仮想マシンのサイズ」を参照してください。 いくつかのノード プールの決定はネットワーク レイアウトに直接影響するため、ネットワークのサイズを設定する前にコンピューティング容量を計画する必要があります。

次の質問に回答すると、クラスターのサブネットと IP アドレス範囲を計画するのに役立ちます。

• 使用するノードプールの数はいくつですか? 必要なサブネットの数は、ノード プールの数によって決まります。 すべてのプールがクラスターの既定のワーカー サブネットを共有する場合は、1 つのサブネットで十分です。 異なるプールに個別のサブネットを割り当てると、それぞれが仮想ネットワークとマシンの CIDR 要件に追加されます。
• 複数の可用性ゾーンにデプロイしますか? 各ノード プールは、1 つの可用性ゾーンにデプロイされます。 高可用性のために複数のゾーンにワークロードを分散するには、個別のノード プールと、ゾーンごとに異なるサブネットが必要な場合があります。 ゾーンが多いほど、サブネットが増え、マシンの CIDR が大きくなります。
• 各ノード プールは独自のサブネットを使用しますか? 別のサブネットを指定しない限り、ノード プールはクラスターの既定のワーカー サブネットにデプロイされます。 サブネットを分離すると、ノード プール間でネットワークが分離されますが、各サブネットはマシンの CIDR 範囲と仮想ネットワーク アドレス空間内に収まる必要があります。
• ピーク時に実行されるノードの数はいくつですか? ノードの最大数 (自動スケールの最大値を含む) によって、各サブネットの大きさが決まります。 クラスターでは、すべてのプールで最大 500 ノードの合計がサポートされます。
• 後でノード プールを追加しますか? クラスターの CIDR 範囲は、作成後に変更することはできません。 今後、新しいサブネットを含むノード プールを追加する予定の場合は、マシン CIDR と仮想ネットワークに対応できる十分なアドレス空間が必要です。

サブネットの要件

仮想ネットワークには、次のコンポーネントが含まれている必要があります。

• ワーカー サブネット - クラスターのワーカー ノードがデプロイされる既定のサブネット。 ノード プールを作成すると、別のサブネットを指定しない限り、このサブネットにデプロイされます。 複数の可用性ゾーンにノード プールをデプロイする予定の場合は、ゾーンごとに個別のサブネットを作成できます。 すべてのノード プール サブネットは、クラスターと同じ仮想ネットワーク内にある必要があります。 各サブネットのサイズは、その中で実行する予定のワーカー ノードの数に基づいて行います。
• VNet 統合サブネット - ホストされたコントロール プレーン (Red Hat の Azure アカウントで実行) とサブスクリプション内のワーカー ノード間のプライベート接続を可能にする専用サブネット。 次の要件を満たす必要があります。
  • /28 の最小サイズ
  • ワーカー サブネットと同じ仮想ネットワークに配置されている
  • ワーカー サブネットまたはノード プール サブネットと共有されない
• ネットワーク セキュリティ グループ - ネットワーク セキュリティ グループ (NSG) をワーカー、ノード プール、または VNet 統合サブネットに関連付ける場合は、「 必要なネットワーク セキュリティ グループ トラフィック」で説明されている必要なトラフィックに対する規則を確認します。 NSG はサブネットに直接割り当てます。

ネットワーク セキュリティ グループに必要なトラフィック

ノード プールと VNet 統合サブネットに関連付けられているネットワーク セキュリティ グループ (NSG) は、次のトラフィックを許可する必要があります。

これらの接続により、ワーカー ノードは、ホストされた kube-apiserver とホストされたコントロール プレーンに到達できます。 NSG 拒否規則で必要なトラフィックがブロックされている場合、ノード プールを作成することはできません。

必要なフローをブロックする拒否ルールを修正するには、次のいずれかのアクションを実行します。

• 拒否規則を削除します。
• 必要な送信元、宛先、ポートと一致しないように拒否ルールを絞り込みます。
• 必要な送信元、宛先、およびポートに一致し、拒否規則よりも優先度が高い許可規則を追加します。 NSG では、数値の優先度が低いほど優先度が高くなります。

ホストされたコントロール プレーンを使用したAzure Red Hat OpenShiftは、必要なポートを含む TCP 規則とワイルドカード 規則を評価します。 関連付けられていないポート、UDP トラフィック、または関連のない宛先の拒否規則は、この検証には影響しません。 ただし、これらのルールは引き続き他のトラフィックをブロックできます。

CIDR の要件

次の表では、仮想ネットワークと CIDR の要件について説明します。

要件を満たしていない場合は、既定値を使用します。 これらの値のいずれかを変更する必要がある場合は、次のガイドラインに従ってください。

• ポッド、サービス、およびマシンの CIDR が互いに重複しないようにする必要があります。
• ポッドとサービスのCIDRは、ネットワーク上で使用されているアドレス範囲、またはクラスター内からアクセスされる外部サービスと重複してはなりません。
• マシン CIDR には、ワーカー サブネット、追加のノード プール サブネット、VNet 統合サブネットなど、クラスターで使用されるすべての仮想ネットワーク サブネットが含まれている必要があります。 将来的に個別のサブネットを持つノード プールを追加する予定の場合は、マシン CIDR がそれらを含めるのに十分な大きさであることを確認してください。 たとえば、VNet で 10.0.0.0/16が使用されている場合、 10.0.0.0/16 の既定のマシン CIDR はすべてのサブネットを対象とします。
• ポッド ネットワークはルーティング不可能な IP アドレスを使用し、クラスターのソフトウェア定義ネットワーク内でのみ使用されます。

プライベート クラスター接続

プライベート API サーバー、プライベートの既定のイングレス、またはその両方を選択した場合は、クラスターをデプロイする前に、ユーザーのネットワークとクラスターの仮想ネットワークの間にプライベート ネットワーク接続を確立する必要があります。 この接続がないと、管理者、CI/CD パイプライン、エンド ユーザーはプライベート エンドポイントに到達できません。

一般的な接続オプションは次のとおりです。

• Azure VNet ピアリング - 2 つのAzure仮想ネットワークを接続して、各ネットワーク内のリソースが相互に通信できるようにします。
• Azure VPN Gateway - サイト間 VPN トンネル経由で、オンプレミス ネットワークをクラスターの仮想ネットワークに接続します。
• Azure ExpressRoute - オンプレミス ネットワークから接続プロバイダー経由でAzureする専用のプライベート接続を確立します。

プライベート ネットワーク接続を計画するときは、ピアリングされたネットワークまたは接続されているネットワークの IP アドレス範囲がクラスターのマシン CIDR、ポッド CIDR、またはサービス CIDR 範囲と重複しないようにします。

次のステップ