Azure CNI、CNI Overlay、Kubenetの違いを正しく理解することは、AKSのネットワーク設計を決めるうえで欠かせません。どのネットワーク方式を選ぶかによって、Pod間の通信方法、IPアドレスの割り当て方、そしてクラスターで利用できる機能が大きく変わります。いずれの方式もPod間の接続を実現できますが、実装方法、パフォーマンス特性、スケーラビリティの観点で違いがあります。本記事ではAzure CNI（従来モードおよびOverlayモード）とKubenetの主な違いを、IPアドレス管理、ネットワークパフォーマンス、統合機能の観点から技術的に整理し、AKSのネットワーク戦略を立てるうえでのヒントをお届けします。
IPアドレス管理
従来のAzure CNIでは、各PodはAzure Virtual Networkのサブネットから直接IPアドレスを受け取ります。つまりPodはVNet内で第一級のネットワーク構成要素として扱われ、Azure環境内の他のリソースと直接通信できます。Pod IPはルーティング可能で、当該サブネットに到達できるリソースであれば直接アクセスできます。
現在Azure CNIにはOverlayモードも用意されています。このモードでサブネットにデプロイされるのはクラスターのノードのみで、PodにはノードをホストするVNetとは論理的に独立したプライベートCIDRからIPアドレスが割り当てられます。クラスター内のPodおよびノード間トラフィックはOverlayネットワークを利用し、クラスター外のリソースへ到達する際はNAT（ネットワークアドレス変換）によりノードのIPアドレスが使われます。この方式によりIPアドレスを大幅に節約でき、クラスターをはるかに大規模に拡張できます。
Kubenetもオーバーレイネットワークを採用しています。PodはVNetに属さない別のアドレス空間からIPアドレスを受け取ります。Podがクラスター外のリソースと通信する際は、KubenetがNATを介してノードのIPアドレス経由でトラフィックをルーティングします。ネットワークホップがひとつ増えますが、サブネットからIPを必要とするのはノードだけになるため、VNetのIPアドレスを節約できます。
サブネット領域の要件
従来のAzure CNIでは、各Podがサブネットから専用のIPアドレスを必要とするため、サブネット設計には十分な配慮が必要です。すべてのノードと、それらが起動しうる最大数のPodを収容できる十分な大きさのサブネットを確保しなければなりません。たとえばノードあたり30 Podを実行し、10ノードまでスケールする想定であれば、Pod用に少なくとも300個のIPアドレスに加えてノード自身のIPも必要になります。この要件のために大きめのCIDR範囲を選ばざるを得なくなり、ネットワーク全体の設計に影響することも少なくありません。
Azure CNI Overlayでは、クラスター作成時に指定したプライベートCIDRから各ノードに/24のアドレス空間が割り当てられるため、IPアドレスをより効率的に活用できます。/24ブロックは固定で、ノードあたり最大250 Podまでサポートします。同じVNet内であれば複数の独立したAKSクラスター間で同じPod CIDRを再利用できるため、コンテナ化アプリケーションで利用可能なIP空間が大きく広がります。
KubenetもIPアドレスを効率的に利用できます。VNet IPが必要なのはノードだけだからです。Podはオーバーレイネットワーク用の内部CIDR範囲（既定では10.244.0.0/16）を使用し、VNetのアドレス空間を消費しません。そのため、利用可能なIPが限られた環境や、IPアドレスに厳しい制約がある環境ではKubenetが有力な選択肢になります。ただしこの効率性と引き換えに、ユーザー定義ルート（UDR）による追加のルーティング設定が必要になります。
ネットワークパフォーマンス
従来のAzure CNIは、ネットワークと直接統合される方式により高いパフォーマンスを発揮します。Podはオーバーレイを介さずにVNetへ直接接続するため、ネットワークスタックのオーバーヘッドが最小限に抑えられます。ネットワークパケットは追加のカプセル化や変換レイヤーを経ずにPodと他のVNetリソース間を直接流れるため、ネットワーク負荷の高いworkloadsでも低レイテンシーかつ高スループットを実現できます。
Azure CNI Overlayは、VNet内のVMと同等のパフォーマンスを維持します。Pod間トラフィックをトンネリングするためのカスタムルートのプロビジョニングやカプセル化処理が不要なため、VNet内のVMに匹敵するPod間接続性能が得られます。
Kubenetでは、ノードのネットワークインターフェイスを介したNATとルーティングが必要なため、ネットワークオーバーヘッドが追加で発生します。各パケットはオーバーレイネットワークで処理され、Podの内部IPアドレスとノードの外部IPアドレスとの間で変換されます。多くのアプリケーションではこの影響はごくわずかですが、高スループットを要するシナリオやレイテンシーに敏感なworkloadsでは無視できない場合があります。
ネットワークセキュリティグループ（NSG）の制御
Azure CNIはサブネットおよびネットワークインターフェイスのレベルでNSGと連携し、Pod IPはVNetの一部であるためルールの対象にできます。NSGを個々のPodに直接アタッチすることはできませんが、VNet IPを介して特定のPodやPodグループを対象にしたNSGルールを作成できます。
Azure CNI Overlayでは、Pod間トラフィックはカプセル化されず、サブネットのNSGルールが適用されます。クラスターを正しく動作させるには、ノードCIDR範囲とPod CIDR範囲の間のトラフィックなど、特定のルール設定が必要です。workloadsのトラフィック制御にはネットワークポリシーの利用が推奨されます。
Kubenetでは、PodがVNetのIPアドレスを直接持たないため、ネットワークセキュリティの制御はノードレベルに限定されます。NSGルールを適用できるのはノードのネットワークインターフェイスのみで、ノード上のすべてのPodが同じネットワークセキュリティルールを共有することになります。この制限のため、Pod単位のネットワークポリシーを実装するのは難しく、クラスター内でよりきめ細かなトラフィック制御を行うにはKubernetes Network Policiesなどの代替手段が必要になることがあります。
VNet統合
従来のAzure CNIは包括的なVNet統合を提供し、PodはVNetに接続されたAzure環境内のあらゆるリソースと直接通信できます。これにはSQL Managed Instance、Azure Cache for Redis、ピアリング先のVNet内のリソースといったAzureサービスが含まれます。PodはVNetサブネットから直接IPアドレスを取得するため、追加のネットワーク設定なしで直接接続を確立でき、他のAzureサービスとシームレスに連携したいシナリオに最適です。
Azure CNI OverlayはNATを介してVNetと統合され、Podからの送信トラフィックにはノードのIPアドレスが使用されます。Podにクラスター外から直接アクセスすることはできませんが、Pod上のアプリケーションをKubernetesのLoad Balancerサービスとして公開すれば、VNet経由で到達できるようになります。
KubenetのVNet統合機能はやや限定的です。Podは外部リソースと通信できますが、Podのオーバーレイネットワークとそれを正しくルーティングするためのUDRが必要です。このルーティングの複雑さが特定のAzureサービスとの接続に影響することがあり、VNetピアリングやハイブリッドネットワーク構成では追加設定が必要になる場合があります。ネットワーク構成が大規模になるほど、ルーティングの要件も複雑になりがちです。
ルートテーブル管理とセットアップの複雑さ
ルートテーブル管理は方式によって大きく異なります。従来のAzure CNIではPodがVNet上で直接通信するため、Podトラフィック用に追加のルートテーブルエントリを設ける必要がなく、ルート管理がシンプルです。クラスターをスケールしてもルーティング構成は単純なままです。一方で、初期セットアップ時には慎重なIPアドレス計画が必要となるトレードオフがあります。
Azure CNI Overlayは、Kubenetと異なり基本的な接続にUDRを必要とせず、Podネットワーキングをシンプルに保ちます。クラスターを正しく動作させるには特定のNSGルールを設定する必要がありますが、Pod間ルーティングは自動で処理され、従来のVNet通信に匹敵するパフォーマンスを維持します。強制トンネリングやカスタムルーティングなど特定のシナリオでは、引き続きUDRが必要になる場合があります。
KubenetはPod接続のためにUDRとIPフォワーディングを利用しますが、これらは既定でAKSサービスが自動的に作成・管理します。任意で独自のルートテーブルを持ち込んで管理することも可能ですが、標準のセットアップでは手動でのルートテーブル管理は不要です。主な制約は、AzureがUDRで最大400ルートまでしかサポートしないため、クラスターが事実上400ノードに制限される点です。サブネットにはノードIP分だけを確保すればよいので、初期セットアップは従来のAzure CNIより簡単で、大規模なIPアドレス計画も不要です。ただしUDRアーキテクチャではネットワークホップが1つ増えるためPod通信にわずかなレイテンシーが発生し、複数のKubenetクラスター間でサブネットを共有することもできません。
追加機能
各ネットワーキング方式でサポートされる高度な機能は異なります。従来のAzure CNIは最も幅広い機能をサポートし、Windowsコンテナ、Azure Network Policies、Application Gateway統合などが利用できます。Azure CNI OverlayはWindowsコンテナと各種ネットワークポリシー（Azure、Calico、Cilium）をサポートしますが、Application GatewayをIngress Controllerとして利用することはできません。両CNIモードともデュアルスタックネットワーキングに対応していますが、Overlayにはいくつかの制限があります。Kubenetはサポート範囲がより狭く、LinuxコンテナとCalicoのネットワークポリシーにのみ対応します。また、Linuxコンテナのみに限定され、ノードあたり最大250 Pod、最大400ノードまでで、ネットワークポリシーもCalicoに限られます。Windowsコンテナや高度なAzureネットワーク機能はサポートされません。
どれを選ぶべきか？
ネットワーキング方式の選択は、workloadsの要件とインフラの制約次第です。
従来のAzure CNIは、ネットワークと直接統合したい、高いパフォーマンスが必要、あるいは高度なAzureサービスとの連携が求められるエンタープライズworkloadsに最適です。次のような場合に選びます。
- 利用可能なIPアドレス空間に余裕がある
- Pod通信の大半がクラスター外のリソース宛である
- クラスター外のリソースからPodへ直接到達する必要がある
- 仮想ノードなどの高度なAKS機能を利用したい
- Application Gateway統合が必要
Azure CNI Overlayは、IPアドレス空間が限られた大規模デプロイに最適です。次のような場合に選びます。
- 大量のPodへスケールしたいが、IPアドレス空間が限られている
- Pod通信の大半がクラスター内で完結する
- よりシンプルなネットワーク構成にしたい
- Windowsコンテナのサポートは必要だが、Application Gateway Ingress Controllerは不要
- クラスターをまたいでPod CIDR範囲を再利用したい
Kubenetは、基本的なLinux workloadsやIPアドレスに制約のある環境に適しています。次のような場合に選びます。
- Linuxのみの基本的なworkloadsである
- IPアドレスに制約があるが、CNI Overlayほどのスケールは不要
- 高度なネットワーキング機能を必要としない
- 開発環境やテスト環境を構築する
AKSクラスターのネットワーキングプラグインの選択は、スケーラビリティ、パフォーマンス、運用の複雑さに長期的な影響を及ぼします。各方式の特徴と制限を正しく理解することは、インフラ要件と将来の成長計画に沿った的確な意思決定を行ううえで欠かせません。ネットワーキング方式の切り替えには通常クラスターの再作成が必要になるため、AKSの計画段階のなるべく早い時期に決めておきましょう。
もう一点補足です。2028年3月31日にAKSのkubenetネットワーキングは廃止されます。Kubenetの多くの制限を解消しつつ効率的なIPアドレス利用も維持できる移行先として、Azure CNI Overlayの採用をご検討ください。
クラウド環境の効率性、コスト効果、セキュリティを最大化する方法については、ぜひDoiTまでお問い合わせください。DoiTなら、コンサルティング、スキル向上、サポートのいずれにおいてもシニアレベル限定のクラウド専門知識を活用でき、専門家のアドバイス、セカンドオピニオン、新技術の導入支援、本番環境の障害対応まで、必要なときにいつでもサポートします。
クラウドセキュリティやアーキテクチャに関する他のトピックを深掘りしたい方は、クラウドエンジニアリングブログもぜひご覧ください。