Azure CNI Overlayと従来のAzure CNIの主な違いは何ですか？

Azure CNI Overlayは、PodがVNETの一部ではないプライベートCIDR範囲を使用することを可能にするのに対し、従来のCNIはすべてのPodにVNETサブネットから実際のIPを割り当てます。これにより、IP枯渇を防ぎ、はるか大規模なクラスターを可能にします。

2026年にAzure CNI OverlayがKubenetよりも推奨される理由は何ですか？

KubenetはAzure UDRの制限により400ノードに制限され、遅延が高くなります。Overlayは最大5,000ノードをサポートし、UDRルーティングのオーバーヘッドなしでほぼワイヤースピードのパフォーマンスを提供します。

Azure CNIでCiliumデータプレーンを使用する利点は何ですか？

kube-proxyのiptablesをeBPFに置き換えることで、より高速なサービスロードバランシング、CPU使用率の低下、そしてHubbleオブザーバビリティによる高性能なセキュリティポリシーを提供します。

既存のKubenetクラスターをAzure CNI Overlayに移行できますか？

いいえ、クラスターが作成された後にnetwork-pluginまたはplugin-modeを切り替えることはできません。KubenetからOverlayに移行するには、クラスターまたはノードプールを再作成する必要があります。

Azure CNI OverlayのPod CIDRには何を使用すべきですか？

Podには標準の169.254.0.0/16または10.244.0.0/16範囲を使用してください。これらがService CIDRやピアリングまたはVPN経由でルーティングする必要があるVNET範囲と重複しないことを確認してください。

Overlayは送信元IPの保持にどう影響しますか？

Overlayモードでは、Podから内部LBへのトラフィックは保持され、送信元IPは通常クラスター内のPod IPですが、クラスター外に出る際にはノードのIPにSNATされます。

Azure AKSネットワーキング: Azure CNI Overlay + Ciliumが2026年唯一の論理的選択である理由

2026年、Azure Kubernetes Service (AKS) ネットワーキングに関する議論はついに終結しました。もしあなたがKubenetまたは従来のAzure CNI（Pod-in-VNET）をデプロイしているなら、それは技術的負債を積み重ねていることになります。Azure CNI Overlayは企業規模のデファクトスタンダードとして台頭し、IP枯渇の悪夢を効果的に解消しつつ、ワイヤースピードに近いパフォーマンスを維持しています。PodのIP空間とVNETのアドレス空間を分離することで、OverlayはKubenetのスケールを、高性能かつネイティブなAzure統合を備えたファーストクラスのCNIとして提供し、Ciliumと組み合わせることで、クラウドネイティブネットワーキングスタックの頂点を表します。

Kubenetの終焉と従来のCNIの失敗

Azure CNI Overlayが2026年に不可欠な選択肢である理由を理解するためには、これまでの実装の残骸を見る必要があります。長年、エンジニアは2つの悪から選択することを強いられてきました。Kubenetはシンプルですが、400ノードのルートテーブル制限と追加のNATホップによる高遅延という重荷があり、従来のAzure CNI (VNETモード)はパフォーマンスに優れますが、中規模クラスターをサポートするためだけに大規模な/16または/18サブネットを必要としました。これは、すべてのPodが実際のVNET IPを消費するためです。

典型的なハブアンドスポーク型企業アーキテクチャでは、ネットワークオペレーションチームから/22プレフィックスを取得するだけでも困難です。50ノードクラスターのために2,000個のIPを要求することは、受け入れられませんでした。従来のCNIはエンジニアを「IPアドレス管理 (IPAM) の曲芸」に追い込み、重複する範囲を避けるために複雑なPrivate Link構成を伴うことがよくありました。Azure CNI Overlayは、Podがプライベートな169.254.0.0/16またはルーティング不能な任意のCIDRに存在できるようにすることでこれを解決し、ノードのみが実際のVNET IPを消費します。

アーキテクチャの詳細: Overlayの実際の動作

Azure CNI Overlayモデルでは、ノードがPodのデフォルトゲートウェイとなります。Azureユーザー定義ルート (UDR) に依存し、ルートテーブルごとに400エントリという厳密な制限があるKubenetとは異なり、OverlayはホストサイドのルーティングテーブルとAzure仮想スイッチ (VFP) 内のカプセル化または直接ルーティングメカニズムを含む、より洗練されたアプローチを採用しています。

ノード1上のPod Aがノード2上のPod Bと通信したい場合:

パケットはvethペアを介してPod Aのネットワーク名前空間から出ます。
Azure CNIは宛先IPがOverlay CIDR内にあることを識別します。
パケットは宛先ノードのVNET IPにルーティングされます。
重要なのは、Azure SDNインフラストラクチャがマッピングを処理することです。標準のOverlayモードでは、VXLAN/GeneveオーバーヘッドがMTUに追加されることはなく、これがほぼラインレートのパフォーマンスが見られる理由です。

# 例: Overlayを使用したAKSノードのルートテーブルの確認
# Pod CIDR範囲がローカルブリッジまたはeth0を介してルーティングされていることがわかります
ip route show
default via 10.240.0.1 dev eth0
10.244.0.0/24 dev azure0 proto kernel scope link src 10.244.0.1
169.254.169.254 via 10.240.0.1 dev eth0

Ciliumを搭載したAzure CNI: 新しいゴールドスタンダード

2026年までに、単にOverlayを使用するだけでは不十分です。Ciliumを搭載したAzure CNIをデプロイすべきです。この統合は、従来のkube-proxy（非効率なiptables/IPVSに依存）をeBPFベースのデータプレーンに置き換えます。Standard_D8s_v5インスタンスでのラボテストでは、iptablesからCilium eBPFに切り替えることで、高並行サービスでのCPUオーバーヘッドが25%減少することが観察されました。

この「Combined Mode」の利点は、AzureがCiliumのライフサイクルを管理することです。高性能なロードバランシング、IDベースのセキュリティポリシー、および深いオブザーバビリティ（Hubble）を、Cilium OperatorやCRDを手動で管理することなく利用できます。マイクロセグメンテーションを行っている場合、iptablesはスケーリングの悪夢ですが、Ciliumのセキュリティポリシーに対するO(1)のルックアップ時間は唯一の方法です。

Azure CLIによるスタックの有効化

ポータルでクリック操作をする必要はありません。2026年版のプロダクショングレードクラスターには、以下の仕様を使用してください:

az aks create \
    --resource-group rg-techleague-prod \
    --name aks-core-mesh \
    --network-plugin azure \
    --network-plugin-mode overlay \
    --network-dataplane cilium \
    --pod-cidr 192.168.0.0/16 \
    --service-cidr 10.0.0.0/16 \
    --dns-service-ip 10.0.0.10 \
    --node-vm-size Standard_D4s_v5 \
    --enable-managed-identity

パフォーマンスベンチマーク: Overlay vs. Kubenet vs. Cilium

様々なシナリオでiperf3とwrkテストを実行しました。結果は明確です。内部のPod間トラフィックでは、Azure CNI OverlayはVNETモードのCNIと2～3%の差でパフォーマンスを発揮しますが、KubenetはUDRホップとNATの複雑さにより10～15%の遅延ペナルティを示します。

メトリック	Kubenet	Azure CNI (レガシー)	Azure CNI Overlay + Cilium
IP消費量	低 (ノードあたり1 IP)	極端 (Podあたり1 IP)	低 (ノードあたり1 IP)
遅延 (μs)	145μs	92μs	94μs
スループット (Gbps)	~7.5 Gbps	~9.4 Gbps	~9.3 Gbps
最大ノード数	400 (UDR制限)	VNETサイズに依存	5,000+

セキュリティ: NetworkPoliciesを超えて

標準のNetworkPolicyリソースはOverlayで動作しますが、CiliumデータプレーンはFQDNベースのフィルタリングとL7 (HTTP/gRPC) ポリシーを可能にします。2026年には、IPアドレスによるトラフィックブロックは不十分です。「Pod AはPod Bの/api/v1/healthへのGETリクエストのみ実行できる」と言える必要があります。

Azure CNI Overlayは、Azure Firewallとよりクリーンに統合されます。クラスターから出るトラフィックはノードIPにソースNATされるため、ファイアウォールルールはノードサブネットに基づいて定義でき、これは動的なPod範囲を追跡するよりもはるかに安定しています。エグレス制御にまだ苦労している場合は、AKSエグレスゲートウェイパターンに関するガイドを参照してください。

運用上の落とし穴: MTUとサブネットの罠

利点があるにもかかわらず、エンジニアはしばしばMTU構成で失敗します。Azure VNETは1500のMTUをサポートします。しかし、Overlayを実行している場合、MTUを削減する必要があるという誘惑があります（VXLANは通常1450を必要とするため）。AzureのOverlay実装は高度に最適化されていますが、これをIstioやLinkerdのようなセカンダリサービスメッシュでmTLSとともにラップすると、実効ペイロードサイズが縮小します。大規模なペイロードで散発的な接続リセットが見られる場合は、必ずmss設定を検証してください。

もう一つのよくある間違いは、ノードサブネットのサイズを正しく設定しないことです。PodはVNET IPを消費しませんが、ノードのスケーリング、アップグレードサージ（max-surge）、および内部ロードバランサーのために十分なスペースが必要です。プロダクション環境では、ノード用に/24が絶対最小値です。欲を出して/27を使おうとしないでください。

結論: 常にOverlayを選択する

2026年が深まるにつれて、AKSネットワーキングの選択は明確です。Kubenetは趣味で使う人や何年も手つかずのレガシー環境向けです。従来のAzure CNIは、無尽蔵のIPv4アドレスを持つ人々（そんなものは存在しません）向けです。Azure CNI Overlay + Ciliumは、現代のエンタープライズワークロードに必要なスケール、パフォーマンス、セキュリティを提供する唯一のアーキテクチャです。

TechLeagueでは、数十社のFortune 500企業を、崩壊しつつあったKubenetクラスターから高性能なOverlayアーキテクチャへ移行させるお手伝いをしてきました。もしあなたのネットワークチームがIP割り当てに抵抗したり、ピーク時の負荷で遅延が急増している場合、専門的なアーキテクチャレビューが必要です。techleague.ioで当社のオーダーメイドのコンサルティングオプションを検討し、インフラストラクチャがCI/CDパイプラインのボトルネックにならないようにしてください。