Azure CNI、CNI Overlay、Kubenetの違いを理解することは、AKSのネットワークアーキテクチャを決定する上で非常に重要であり、ネットワーキングのオプションは、ポッドの通信方法、IPアドレスの割り当て方法、およびクラスタで利用可能な機能を決定します！どのソリューションもポッド接続を可能にしますが、実装、パフォーマンス特性、スケーラビリティに関する考慮事項が異なります。この技術概要では、Azure CNI（従来のモードとオーバーレイモードを含む）とKubenetの主な違いを、IPアドレス管理、ネットワークパフォーマンス、統合機能に焦点を当てて検証し、AKSネットワーキング戦略の参考にします。
IPアドレス管理
従来のAzure CNIでは、各PodはAzure仮想ネットワークのサブネットから直接IPアドレスを受け取ります。つまり、ポッドはVNet内で一流のネットワーク市民であり、Azure環境内の他のリソースとの直接通信を可能にします。ポッドのIPはルーティング可能であり、サブネットへのネットワーク接続性を持つすべてのリソースからアクセスできます。
Azure CNI は、クラスタノードのみがサブネットにデプロイされるオーバーレイモードも提供します。Podには、ノードをホストするVNetとは論理的に異なるプライベートCIDRからIPアドレスが割り当てられる。クラスタ内のポッドとノードのトラフィックはオーバーレイネットワークを使用し、ネットワークアドレス変換（NAT）はノードのIPアドレスを使用してクラスタ外のリソースにアクセスします。このソリューションにより、大量のIPアドレスが節約され、クラスタを大幅に拡張できます。
Kubenetはオーバーレイネットワークも実装しています。PodはVNetの一部ではない別のアドレス空間からIPアドレスを受け取ります。Podがクラスタ外のリソースと通信する必要がある場合、KubenetはNATを使用してノードのIPアドレスを介してトラフィックをルーティングします。これにより追加のネットワークホップが作成されますが、ノードのみがサブネットからのIPを必要とするため、VNetのIPアドレスを節約できます。
サブネットの必要スペース
従来のAzure CNIを使用する場合、各ポッド候補にはサブネットからの専用IPアドレスが必要なため、サブネット計画には慎重な検討が必要です。つまり、すべてのノードとそのポッドの最大数を収容できる十分な大きさのサブネットを割り当てる必要があります。つまり、各ノードが30個のポッドを実行でき、10ノードに拡張する予定であれば、ポッド用に少なくとも300個のIPアドレスと、ノード自体の追加IPアドレスが必要になります。この要件により、多くの場合、より大きなCIDR範囲を選択せざるを得なくなり、全体的なネットワーク設計に影響を与える可能性があります。
Azure CNI Overlayは、クラスタ作成時に指定したプライベートCIDRから/24アドレス空間を各ノードに割り当てることで、より効率的なIPアドレス利用を実現します。24ブロックは固定で、ノードあたり最大250ポッドをサポートできます。同じVNet内の複数の独立したAKSクラスタ間で同じポッドCIDRスペースを再利用できるため、コンテナ型アプリケーションで使用できるIPスペースを大幅に拡張できます。
Kubenetはまた、ノード自体にVNet IPのみを必要とするため、効率的なIPアドレス利用を提供します。Podはオーバーレイネットワークに内部CIDR範囲を使用し、通常デフォルトは10.244.0.0/16で、VNetのアドレス空間を消費しません。このため、KubenetはIPの可用性が限られた環境や、IPアドレスの制約が厳しい環境で使用するのに適しています。しかし、この効率性は、ユーザー定義ルート（UDR）による追加のルーティング設定を必要とするというトレードオフを伴います。
ネットワーク・パフォーマンス
従来のAzure CNIは、直接的なネットワーク統合モデルにより、優れたネットワークパフォーマンスを提供します。Podはオーバーレイネットワークを介さずにVNetに直接接続できるため、ネットワークスタックのオーバーヘッドは最小限に抑えられます。ネットワークパケットは、カプセル化や変換レイヤーを追加することなく、ポッドと他のVNetリソース間を直接流れるため、ネットワーク集約型のワークロードでは、レイテンシが低く、スループットが高くなります。
Azure CNI Overlayは、VNet内のVMと同等のパフォーマンスを維持します。カスタムルートをプロビジョニングしたり、ポッド間のトラフィックをトンネルするためにカプセル化方式を使用したりする必要がないため、VNet内のVMと同等のポッド間の接続パフォーマンスが得られます。
Kubenetでは、NATとノードのネットワークインターフェイスを介したルーティングが必要なため、追加のネットワークオーバーヘッドが発生します。各パケットはオーバーレイネットワークによって処理され、ポッドの内部IPアドレスとノードの外部IPアドレスの間で変換される必要があります。このパフォーマンスへの影響は、多くのアプリケーションでは最小ですが、高いネットワークスループット要件やレイテンシに敏感なワークロードがあるシナリオでは顕著になる可能性があります。
ネットワーク・セキュリティ・グループ（NSG）制御
Azure CNI はサブネットおよびネットワークインターフェイスレベルで NSG と連携し、ポッド IP は VNet の一部であるため、ルールはポッド IP をターゲットにできます。NSG を個々のポッドに直接アタッチすることはできませんが、VNet IP を通じて個々のポッドまたはポッド グループをターゲットとする特定の NSG ルールを作成できます。
Azure CNI Overlayでは、ポッド間のトラフィックはカプセル化されず、サブネットNSGルールが適用されます。ノード CIDR 範囲とポッド CIDR 範囲間のトラフィックなど、適切なクラスタ機能を実現するには特定のルールが必要です。ワークロードのトラフィック制御にはネットワークポリシーを推奨します。
Kubenet では、ポッドが直接 VNet IP アドレスを持たないため、ネットワーク・セキュリティの制御はノード・レベルに限定される。NSG ルールはノードのネットワーク・インターフェースにしか適用できないため、ノード上のすべてのポッドが同じネットワーク・セキュリティ・ルールを共有することになります。この制限により、Pod固有のネットワーク・ポリシーを実装することが難しくなり、クラスタ内でよりきめ細かいトラフィック制御を行うには、Kubernetes Network Policiesのような代替ソリューションが必要になる可能性がある。
VNetインテグレーション
従来のAzure CNIは、包括的なVNet統合を提供し、ポッドがVNetに接続されているAzure環境のあらゆるリソースと直接通信できるようにします。これには、SQL Managed Instances、Azure Cache for RedisなどのAzureサービスや、ピアリングされたVNet内のリソースが含まれます。PodはVNetサブネットから直接IPアドレスを取得するため、追加のネットワーク設定なしで直接接続を確立でき、他のAzureサービスとのシームレスな統合を必要とするシナリオに最適です。
Azure CNI OverlayはNATを通じてVNet統合を提供し、アウトバウンドのポッドトラフィックはノードのIPアドレスを使用する。クラスタ外からPodに直接アクセスすることはできませんが、PodアプリケーションをKubernetes Load Balancerサービスとして公開することで、VNet上で到達可能にすることができます。
Kubenetはより限定的なVNet統合機能を提供します。Podは外部リソースと通信できますが、この通信には、PodオーバーレイネットワークとVNet間のトラフィックを適切にルーティングするためのUDRが必要です。このルーティングの複雑さが増すと、特定の Azure サービスとの接続性に影響を与える可能性があり、VNet ピアリングやハイブリッドネットワークシナリオで作業する場合は、余分な設定が必要になる場合があります。また、ネットワークアーキテクチャが大きくなるにつれて、ルーティング要件も複雑になる可能性があります。
ルートテーブルの管理とセットアップの複雑さ
ルートテーブル管理は、オプションによって大きく異なります。従来のAzure CNIでは、ポッドがVNet上で直接通信し、ポッドのトラフィックを処理するためにルートテーブルエントリを追加する必要がないため、ルート管理が簡素化されます。クラスタがスケールしても、ルーティング設定は簡単なままです。トレードオフは初期設定の複雑さで、慎重なIPアドレス計画が必要になります。
Azure CNI Overlay は、Kubenet とは異なり、基本的な接続に UDR を必要としないため、ポッドネットワーキングを簡素化します。適切なクラスタ機能を実現するために特定の NSG ルールを設定する必要はありますが、このソリューションは自動的にポッド間のルーティングを処理し、従来の VNet 通信に匹敵するパフォーマンスを維持します。強制的なトンネリングやカスタム・ルーティングの要件など、特定のシナリオでは UDR が必要になる場合があります。
Kubenetはポッド接続のためにUDRとIPフォワーディングを使用します。これらはデフォルトでAKSサービスによって自動的に作成され、維持されます。オプションで独自のルートテーブルを持ち込んでカスタム管理することもできるが、標準のセットアップではルートテーブルのメンテナンスを手動で行う必要はない。主な制限は、Azureが1つのUDRでサポートする最大ルート数が400であるため、クラスタが実質的に400ノードに制限されることだ。大規模なIPアドレス計画は必要なく、サブネット内のノードIPを考慮するだけでよいため、初期設定は従来のAzure CNIよりもシンプルです。しかし、UDRアーキテクチャは、ポッド通信にわずかな遅延をもたらす余分なネットワークホップを追加し、複数のKubenetクラスタ間でサブネットを共有することはできません。
その他の特徴
各ネットワーキングオプションは、それぞれ異なる高度な機能をサポートしている。従来の Azure CNI は、Windows コンテナ、Azure ネットワークポリシー、Application Gateway の統合など、最も幅広い機能をサポートしている。Azure CNI Overlayは、Windowsコンテナと様々なネットワークポリシーオプション（Azure、Calico、Cilium）をサポートするが、Ingress ControllerとしてApplication Gatewayを使用することはできない。どちらのCNIモードもデュアルスタックネットワーキングをサポートするが、Overlayにはいくつかの制限がある。Kubenetは、LinuxコンテナとCalicoネットワークポリシーでのみ動作し、より限定的な機能をサポートしている。また、KubenetはLinuxコンテナのみに限定され、ノードあたり250ポッドで最大400ノードをサポートし、ネットワークポリシーはCalicoに限定される。Windowsコンテナや高度なAzureネットワーキング機能には対応していない。
どちらを選ぶべきか？
ネットワーク・オプションの選択は、特定のワークロード要件とインフラストラクチャの制約に依存します：
従来のAzure CNIは、直接的なネットワーク統合、高パフォーマンス、または高度なAzureサービス統合を必要とするエンタープライズワークロードに最適です。次のような場合に選択します：
- IPアドレスに空きがある
- ほとんどのポッド通信はクラスタ外のリソースに対して行われる
- クラスタ外のリソースはポッドに直接到達する必要がある
- 仮想ノードなどの高度なAKS機能が必要
- アプリケーションゲートウェイの統合が必要
Azure CNIオーバーレイは、IPアドレススペースが限られている大規模な導入に最適です。次のような場合に選択します：
- 多数のポッドに拡張する必要があるが、IPアドレスのスペースが限られている。
- ほとんどのポッド通信はクラスタ内で行われる
- よりシンプルなネットワーク構成にしたい
- Windowsコンテナのサポートは必要だが、Application Gateway Ingress Controllerは必要ない。
- クラスタ間でポッドのCIDR範囲を再利用したい
Kubenetは、基本的なLinuxワークロードや、IPアドレスの制約がある環境に適しています。次のような場合に選択してください：
- 基本的なLinuxのみのワークロード
- IPアドレスの制約があるが、CNIオーバーレイの規模は必要ない。
- 高度なネットワーク機能は必要ない
- 開発環境やテスト環境を構築する
AKSクラスタのネットワークプラグインの選択は、スケーラビリティ、パフォーマンス、および運用の複雑性に長期的な影響を与えます！各オプションの明確な特性と制限を理解することは、インフラストラクチャの要件と将来の成長計画に沿った情報に基づいた決定を行う上で非常に重要です。ネットワークオプションを切り替えるには、通常クラスタの再作成が必要なため、この決定はAKSの計画プロセスの早い段階で行う必要があることを覚えておいてください。
2028年3月31日にAKSのkubenetネットワーキングは引退します。効率的なIPアドレス利用を維持しながら、Kubenetの制限の多くに対処する適切な代替手段として、Azure CNI Overlayへの移行を検討してください。
クラウド環境の効率性、費用対効果、セキュリティの最大化について、DoiTにご相談ください。DoiTでは、コンサルティング、スキルアップ、サポートなど、クラウドに関するシニアの専門知識をご利用いただけます。専門的なアドバイスや外部の意見、新しいテクノロジーの導入支援、本番環境での消火活動など、必要なときにいつでもご相談ください。
その他のクラウドセキュリティやアーキテクチャのトピックに興味がある方は、クラウドエンジニアリングのブログ記事をご覧ください。
