Azure Container Networking Interface (CNI) オーバーレイ ネットワーク
Azure CNI オーバーレイを使用する場合、クラスター ノードは Azure Virtual Network (VNet) サブネットにデプロイされます。 ポッドには、ノードをホストしている VNet とは論理的に異なるプライベート CIDR から IP アドレスが割り当てられます。 クラスター内のポッドとノードのトラフィックは、オーバーレイ ネットワークを使用します。 ネットワーク アドレス変換 (NAT) では、ノードの IP アドレスを使用してクラスターの外部のリソースに到達します。 このソリューションにより、VNet IP アドレスが大幅に節約され、クラスターを大きなサイズにスケーリングできます。 さらに、プライベート CIDR を異なる AKS クラスターで再利用できるため、Azure Kubernetes Service (AKS) のコンテナー化されたアプリケーションで使用できる IP 空間が拡張されるというメリットもあります。
オーバーレイ ネットワークの概要
オーバーレイ ネットワークでは、Kubernetes クラスター ノードのみにサブネットから IP が割り当てられます。 ポッドは、クラスター作成時に提供されるプライベート CIDR から IP を受け取ります。 各ノードには、同じ CIDR から分割された /24 アドレス空間が割り当てられます。 クラスターのスケールアウト時に作成される追加のノードは、同じ CIDR から /24 アドレス空間を自動的に受け取ります。 Azure CNI は、この /24 空間からポッドに IP を割り当てます。
ポッドのプライベート CIDR 空間用の別のルーティング ドメインが Azure ネットワーク スタックに作成され、これによりポッド間の直接通信用オーバーレイ ネットワークが作成されます。 クラスター サブネットにカスタム ルートをプロビジョニングする必要も、カプセル化の方法を使ってポッド間でトラフィックをトンネリングする必要もなく、VNet 内の VM と同等のポッド間の接続パフォーマンスが提供されます。 ポッド内で実行されているワークロードでは、ネットワーク アドレスの操作が行われているということさえ検知されません。
オンプレミスやピアリングされた VNet など、クラスター外のエンドポイントとの通信は、NAT を介し、ノード IP を使用して行われます。 Azure CNI は、トラフィックのソース IP (ポッドのオーバーレイ IP) を VM のプライマリ IP アドレスに変換し、Azure ネットワーク スタックがトラフィックを宛先にルーティングできるようにします。 クラスター外のエンドポイントは、ポッドに直接接続できません。 ポッドのアプリケーションを Kubernetes Load Balancer サービスとして公開して、VNet でアクセスできるようにする必要があります。
オーバーレイ ポッドのインターネットへのアウトバウンド (エグレス) 接続は、Standard SKU Load Balancer またはマネージド NAT Gateway を使用して提供できます。 また、クラスター サブネット上のユーザー定義ルートを使用してファイアウォールに送信することで、エグレス トラフィックを制御することもできます。
クラスターへのイングレス接続は、Nginx や HTTP アプリケーション ルーティングなどのイングレス コントローラーを使用して実現できます。 Azure Application Gateway を使ったイングレス接続を構成することはできません。 詳細については、Azure CNI オーバーレイの制限事項に関するページを参照してください。
kubenet と Azure CNI オーバーレイの違い
次の表は、kubenet と Azure CNI オーバーレイを詳細に比較したものです。
| 領域 | Azure CNI オーバーレイ | kubenet |
|---|---|---|
| クラスターのスケール | 5,000 ノードと 250 ポッド/ノード | 400 ノードと 250 ポッド/ノード |
| ネットワーク構成 | シンプル - ポッド ネットワークに対する追加の構成は不要 | 複雑 - ポッド ネットワークのクラスター サブネットにルート テーブルと UDR が必要 |
| ポッド接続のパフォーマンス | VNet 内の VM と同等のパフォーマンス | ホップを追加すると、待機時間がわずかに増加 |
| Kubernetes ネットワーク ポリシー | Azure ネットワーク ポリシー、Calico、Cilium | Calico |
| サポートされている OS プラットフォーム | Linux と Windows Server 2022、2019 | Linux のみ |
IP アドレス計画
クラスター ノード
AKS クラスターを設定する際には、VNet サブネットに拡張できる余裕が十分にあり将来のスケーリングが可能であることを確認します。 各ノード プールを専用サブネットに割り当てることができます。
最初の 3 つの IP アドレスは管理タスク用に予約されているため、/24 サブネットが適合できるノード数は 251 までです。
ポッド
オーバーレイ ソリューションは、クラスター作成時に指定されたプライベート CIDR から各ノードのポッドに /24 アドレス空間を割り当てます。 /24 サイズは固定で、増減はできません。 1 つのノードで最大 250 個のポッドを実行できます。
ポッドの IP アドレス空間を計画する場合は、次の要因を考慮してください。
- 将来のクラスター拡張をサポートするために、プライベート CIDR が新しいノードに対して
/24アドレス空間を提供するのに十分な大きさであることを確認します。 - 同じポッド CIDR 空間は、同じ VNet 内の独立した複数の AKS クラスターで使用できます。
- ポッド CIDR 空間は、クラスターのサブネット範囲と重複することはできません。
- ポッド CIDR 領域は、直接接続されたネットワーク (VNet ピアリング、ExpressRoute、VPN など) と重複してはなりません。 外部トラフィックに podCIDR 範囲のソース IP がある場合、クラスターと通信するには、SNAT を介して重複しない IP に変換する必要があります。
Kubernetes サービスのアドレス範囲
サービス アドレス CIDR のサイズは、作成する予定のクラスター サービスの数によって異なります。 /12 より小さくする必要があります。 また、この範囲は、ピアリングされた VNet およびオンプレミス ネットワークで使用されるポッド CIDR 範囲、クラスター サブネット範囲、および IP 範囲と重複しないようにする必要があります。
Kubernetes DNS サービスの IP アドレス
この IP アドレスは、クラスター サービスの検出で使用される Kubernetes サービス アドレス範囲内のものです。 アドレス範囲の最初のIP アドレスは、 kubernetes.default.svc.cluster.local のアドレスとなるため、使用しないでください。
ネットワーク セキュリティ グループ
Azure CNI オーバーレイを使用したポッド間トラフィックがカプセル化されず、サブネット ネットワーク セキュリティ グループ ルールが適用されます。 サブネット NSG にポッド CIDR トラフィックに影響を与える拒否ルールが含まれている場合は、(すべての AKS エグレス要件に加えて) 適切なクラスター機能を確保するために、次のルールが定められていることを確認します。
- ノード CIDR からすべてのポートとプロトコルのノード CIDR へのトラフィック
- ノード CIDR からすべてのポートとプロトコルのポッド CIDR へのトラフィック (サービス トラフィック ルーティングに必要)
- ポッド CIDR からすべてのポートとプロトコルのポッド CIDR へのトラフィック (ポッド間、ポッドからサービスへのトラフィックに必要、DNS を含む)
ポッドからポッド CIDR ブロック外の任意の宛先へのトラフィックは、SNAT を利用して、ソース IP を、ポッドが実行されるノードの IP に設定します。
クラスター内のワークロード間のトラフィックを制限したい場合は、ネットワーク ポリシーを使用することをお勧めします。
ノードごとの最大ポッド数
ノードごとの最大ポッド数は、クラスター作成時または新しいノード プールの追加時に構成できます。 Azure CNI オーバーレイの既定値と最大値は 250 で、最小値は 10 です。 ノード プールの作成時に構成されたノードごとの最大ポッド数は、そのノード プール内のノードにのみ適用されます。
使用するネットワーク モデルの選択
Azure CNI はポッド向けの IP アドレス指定オプションとして、ポッドに VNet IP を割り当てる従来の構成と、オーバーレイ ネットワーク の 2 つが用意されています。 AKS クラスターに使用するオプションは、柔軟性と高度な構成のニーズのバランスを考慮して選択します。 以下の考慮事項は、それぞれのネットワーク モデルが最も適切である可能性がある状況の概要を理解するのに役立ちます。
次の場合は、オーバーレイ ネットワークを使用します。
- 多数のポッドにスケーリングしたくても、VNet の IP アドレス空間は限られています。
- ポッドのほとんどの通信がクラスター内で行われる。
- 仮想ノードなどの高度な AKS 機能を使用する必要がない。
次の場合は、従来の VNet オプションを使用します。
- 使用可能な IP アドレス空間が十分にある。
- ポッドの通信のほとんどが、クラスターの外部にあるリソースに対するものである。
- クラスター外のリソースがポッドに直接接続する必要がある。
- 仮想ノードなどの高度な AKS 機能を使用する必要がある。
Azure CNI オーバーレイに関する制限事項
Azure CNI オーバーレイには次の制限事項があります。
- Application Gateway をイングレス コントローラーとして使用すること (AGIC) はできません。
- 仮想マシン可用性セット (VMAS) はサポートされていません。
- ノード プールでDCsv2 シリーズの仮想マシンは使用できません。 コンフィデンシャル コンピューティングの要件を満たすには、代わりに DCasv5 または DCadsv5 シリーズの機密 VM の使用をご検討ください。
- クラスターをデプロイするために独自のサブネットを使用している場合は、サブネット、VNet、および VNet を含むリソース グループの名前は 63 文字以下にする必要があります。 これらの名前は、AKS ワーカー ノード内のラベルとして使用され、Kubernetes ラベル構文規則の対象となります。
Azure Kubernetes Service