ホストされたコントロール プレーンを使用するAzure Red Hat OpenShiftは、ワーカー ノードをAzure仮想ネットワークにデプロイし、専用サブネットを使用して、ホストされたコントロール プレーンとワーカー ノードの間にプライベート接続を確立します。 クラスターを作成する前に、仮想ネットワークのレイアウト、サブネット、IP アドレス範囲を計画する必要があります。
コンピューティング容量を計画する
ノード プールはコンピューティング容量を提供します。 ノード プールは、同じ VM サイズ、ディスク構成、および可用性ゾーンを共有するワーカー ノードのグループです。 1 つのクラスターに複数のノード プールを作成して、異なるハードウェアで異なるワークロードの種類を実行できます。 サポートされているワーカー ノード VM のサイズについては、「 サポートされている仮想マシンのサイズ」を参照してください。 いくつかのノード プールの決定はネットワーク レイアウトに直接影響するため、ネットワークのサイズを設定する前にコンピューティング容量を計画する必要があります。
次の質問に回答すると、クラスターのサブネットと IP アドレス範囲を計画するのに役立ちます。
- 使用するノードプールの数はいくつですか? 必要なサブネットの数は、ノード プールの数によって決まります。 すべてのプールがクラスターの既定のワーカー サブネットを共有する場合は、1 つのサブネットで十分です。 異なるプールに個別のサブネットを割り当てると、それぞれが仮想ネットワークとマシンの CIDR 要件に追加されます。
- 複数の可用性ゾーンにデプロイしますか? 各ノード プールは、1 つの可用性ゾーンにデプロイされます。 高可用性のために複数のゾーンにワークロードを分散するには、個別のノード プールと、ゾーンごとに異なるサブネットが必要な場合があります。 ゾーンが多いほど、サブネットが増え、マシンの CIDR が大きくなります。
- 各ノード プールは独自のサブネットを使用しますか? 別のサブネットを指定しない限り、ノード プールはクラスターの既定のワーカー サブネットにデプロイされます。 サブネットを分離すると、ノード プール間でネットワークが分離されますが、各サブネットはマシンの CIDR 範囲と仮想ネットワーク アドレス空間内に収まる必要があります。
- ピーク時に実行されるノードの数はいくつですか? ノードの最大数 (自動スケールの最大値を含む) によって、各サブネットの大きさが決まります。 クラスターでは、すべてのプールで最大 500 ノードの合計がサポートされます。
- 後でノード プールを追加しますか? クラスターの CIDR 範囲は、作成後に変更することはできません。 今後、新しいサブネットを含むノード プールを追加する予定の場合は、マシン CIDR と仮想ネットワークに対応できる十分なアドレス空間が必要です。
ヒント
サイズ設定の例:3 つの可用性ゾーン、ゾーンあたり最大 50 ノード、およびゾーンごとに個別のサブネットを持つクラスターには、3 つの/26 サブネット (それぞれ 64 個のアドレス、50 個のノードとAzure予約済みアドレス) と 1 つの/29 VNet 統合サブネットが必要です。
4 つのサブネットはすべて、 /24 マシン CIDR (256 アドレス) 内に収まります。
後でノード プールを追加する予定の場合は、 /22 や /16 などの大規模なコンピューター CIDR を使用して、追加のサブネットの空き容量を残します。
サブネットの要件
仮想ネットワークには、次のコンポーネントが含まれている必要があります。
- ワーカー サブネット - クラスターのワーカー ノードがデプロイされる既定のサブネット。 ノード プールを作成すると、別のサブネットを指定しない限り、このサブネットにデプロイされます。 複数の可用性ゾーンにノード プールをデプロイする予定の場合は、ゾーンごとに個別のサブネットを作成できます。 すべてのノード プール サブネットは、クラスターと同じ仮想ネットワーク内にある必要があります。 各サブネットのサイズは、その中で実行する予定のワーカー ノードの数に基づいて行います。
-
VNet 統合サブネット - ホストされたコントロール プレーン (Red Hat の Azure アカウントで実行) とサブスクリプション内のワーカー ノード間のプライベート接続を可能にする専用サブネット。 次の要件を満たす必要があります。
-
/29の最小サイズ - ワーカー サブネットと同じ仮想ネットワークに配置されている
- ワーカー サブネットまたはノード プール サブネットと共有されない
-
- ネットワーク セキュリティ グループ - 作成してワーカー サブネットに関連付けるAzureネットワーク セキュリティ グループ。 ネットワーク セキュリティ グループをサブネットに直接割り当てると、変更できません。 変更するアクセス許可がありません。
CIDR の要件
次の表では、仮想ネットワークと CIDR の要件について説明します。
| ネットワーク要件 | デフォルト | 説明 |
|---|---|---|
| マシンの CIDR 範囲 | 10.0.0.0/16 |
コンピューティング ノードの IP アドレス範囲。 追加のノード プールに使用する予定のサブネットを含め、仮想ネットワーク サブネットのすべての CIDR アドレス範囲を含める必要があります。 サブネットは連続している必要があります。 1 つの可用性ゾーンのデプロイでは、少なくとも 128 個のアドレス (/25) がサポートされています。 複数の可用性ゾーンのデプロイでは、少なくとも 256 個のアドレス (/24) がサポートされています。 |
| サービスの CIDR 範囲 | 172.30.0.0/16 |
Kubernetes サービス IP の IP アドレス範囲。 この範囲は、ワークロードに対応できる十分な大きさである必要があり、クラスター内からアクセスされる外部サービスと重複しないようにする必要があります。 |
| ポッドの CIDR 範囲 | 10.128.0.0/14 |
ポッドの IP アドレス範囲。 この範囲は、ワークロードに対応できる十分な大きさである必要があり、クラスター内からアクセスされる外部サービスと重複しないようにする必要があります。 |
| ホスト プレフィックス | 23 |
ポッドの各ノードに割り当てられたサブネット プレフィックスの長さ。
23の値は、ポッド CIDR 範囲からノードごとに/23サブネット (512 IP アドレス) を割り当てます。 |
要件を満たしていない場合は、既定値を使用します。 これらの値のいずれかを変更する必要がある場合は、次のガイドラインに従ってください。
- ポッド、サービス、およびマシンの 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 範囲と重複しないようにします。