AKS ポッド CIDR 拡張が GA に到達したことで、Azure Kubernetes Service ではポッド用 IP の枯渇に対して、クラスター再作成なしで打てる手が増えました。Microsoft のリリースコミュニケーションは 2026年4月7日に公開・更新され、可用性の扱いは 2026年3月の General Availability です。対象は Azure CNI Overlay を使う AKS クラスターですが、当てはまる環境なら IP 枯渇時の再構築や切り替え計画をかなり減らせます。(Microsoft)
要点はシンプルです。これまで Pod IP が尽きると環境の作り直しが現実的な選択肢になりがちでしたが、今後は Pod CIDR をその場で広げられます。ただし、Linux ノード限定、Azure CNI Overlay 限定、CIDR の縮小や不連続追加は不可という条件があります。この記事では、AKS ポッド CIDR 拡張が IP 枯渇回避にどう役立つのかを、判断基準と運用のコツまで含めて整理します。(Microsoft)
AKS ポッド CIDR 拡張が GA に到達した意味
Microsoft の説明では、AKS ポッド CIDR 拡張は overlay ベースの AKS クラスターで pod IP 範囲をインプレースで増やし、クラスター再作成を不要にする機能です。狙いは単なる利便性向上ではなく、可用性を保ったままワークロードを伸ばしやすくし、長期の IP 設計をシンプルにすることにあります。言い換えると、設計時の見積もり違いを運用で吸収しやすくする機能です。(Microsoft)
この変化が大きいのは、AKS の現場で IP 枯渇がそのままスケール停止や移行案件に直結しやすいからです。特に共有基盤クラスターや季節変動の大きいサービスでは、最初に切った Pod CIDR が数か月後に足かせになることがあります。今回の GA によって、そうした“将来の成長で詰む”リスクに対して、後から取れる現実的な選択肢が増えました。(Microsoft)
AKS でポッド CIDR が足りなくなる理由
Azure CNI Overlay では、仮想ネットワークのサブネットから IP を受け取るのはノードだけで、ポッドは別の private CIDR から IP を受け取ります。しかも各ノードには、その pod CIDR から固定の /24 が割り当てられ、1 ノードあたり最大 250 ポッドまでが前提です。つまり IP 枯渇の正体は、「VNet がいっぱい」よりも「新しいノードに配る /24 の在庫が尽きる」ことです。(Microsoft Learn)
たとえば pod CIDR が /18 なら、/24 ブロックは 64 個です。概算では 64 ノード分の余地しかありません。これを /16 まで広げると 256 ノード分になります。ただし、AKS の IP 計画ではアップグレードやスケール時に追加ノード分の余裕が必要です。現在のノード数だけでなく、Cluster Autoscaler の上限、将来の増加、max surge まで含めて見積もらないと、見た目より早く詰まります。(Microsoft Learn)
| Pod CIDR | /24 ブロック数の目安 | ノード数の概算 |
|---|---|---|
/20 | 16 | 約16 |
/19 | 32 | 約32 |
/18 | 64 | 約64 |
/17 | 128 | 約128 |
/16 | 256 | 約256 |
この表は、Azure CNI Overlay が各ノードに固定 /24 を割り当てる仕様を前提にした概算です。実際の上限は、アップグレード時の追加ノード、将来の増加見込み、オートスケール設定を差し引いて考えるのが安全です。(Microsoft Learn)
AKS ポッド CIDR 拡張が特に効くケース
特に効果が大きいのは、すでに Azure CNI Overlay を使っていて、初期設計で小さめの pod CIDR を選んだ既存クラスターです。日本語の構成ドキュメントでは、Overlay の --pod-cidr 既定値は 10.244.0.0/16 とされています。したがって、今回の恩恵が大きいのは、過去に /18 や /19 などを明示的に切って作った環境、あるいは移行時に狭い範囲を選んだ環境です。(Microsoft Learn)
次のようなチームは、AKS ポッド CIDR 拡張の優先度が高めです。(Microsoft Learn)
- 共有基盤クラスターでノード数の上振れが読みづらい
- HPA や Cluster Autoscaler によって短期間でノードが増える
- 多数のポッドにスケールしたいが、VNet 側の IP を節約したい
- 再構築よりも継続運用を優先したい
一方で、外部システムから Pod IP に直接到達させたい要件が強いなら、この GA だけで満足できるとは限りません。Overlay ではクラスター外からポッドへ直接接続できず、公開は LoadBalancer や ingress 経由が基本だからです。「IP を節約したい」と「Pod IP を外部に見せたい」は両立しにくい要件だと理解しておくと、設計判断を誤りにくくなります。(Microsoft Learn)
AKS ポッド CIDR 拡張の条件と制限
AKS ポッド CIDR 拡張をそのまま使える条件は、かなり明確です。(aka.ms)
- ネットワーク モード：Azure CNI Overlay のみ
- OS：Linux ノードのみ。Windows ノードとハイブリッド シナリオは対象外
- Azure CLI：2.48.0 以降
- CIDR の変更条件：既存範囲を丸ごと含む、より大きなスーパーセットにしかできない
- 非対応：縮小、付け替え、不連続追加、複数 CIDR 変更、IPv6 拡張
- 完了判定：更新成功表示だけでは不十分で、
NodeNetworkConfig(nnc) で確認が必要
ここで一つ注意があります。GA の告知は 2026年4月7日ですが、How-to ドキュメントは英語版が 2026年1月15日、日本語版が 2026年2月26日更新で、preview 向けの注意書きや feature flag 登録手順が残っています。現時点では、EnableAzureCNIOverlayPodCIDRExpansion を含む前提条件を「GA だからもう不要」と自己判断せず、実施前に自分のサブスクリプションで要件を確認する運用が安全です。(Microsoft)
Azure CNI Overlay ではないクラスターの考え方
AKS ポッド CIDR 拡張の恩恵を直ちに受けられるのは、すでに Azure CNI Overlay を使うクラスターです。Kubenet や Azure CNI Node Subnet のクラスターは、まず Overlay への移行が前提になります。しかも AKS がサポートする既存クラスターのネットワーク移行は Azure CNI Overlay への一方向のみで、元に戻すことはできません。(Microsoft Learn)
この移行は軽い変更ではありません。Microsoft Learn では、ノード プールの再イメージ化が同時に走り、各ノード プールを個別に更新することはサポートされず、影響はノード イメージ更新や Kubernetes バージョン アップグレードに近いとされています。Kubenet ではルートテーブルの扱いもあり、ユーザー割り当てマネージド ID が必要なケースがあります。つまり「IP が足りないから今日すぐ GA 機能で解決」とは限らず、非 Overlay 環境は移行計画を別立てで組むべきです。(Microsoft Learn)
さらに Cilium も使いたい場合、IPAM モードの Overlay への更新と、データ プレーンの Cilium への更新は 1 回ではできません。まず Overlay へ、その後に Cilium へ、という順序です。ネットワーク変更を一度に詰め込みすぎると切り分けが難しくなるので、変更計画は分離したほうが安全です。(Microsoft Learn)
AKS ポッド CIDR 拡張を進める実務手順
まず確認すること
- 今のクラスターが Azure CNI Overlay か、Linux ノードかを確認する
ここが外れていると、今回の GA をそのまま使えません。(aka.ms) - 必要な
/24ブロック数を計算する
目安は「将来の最大ノード数 + アップグレード余裕 + 追加の成長分」です。現在 40 ノードでも、繁忙期 60 ノード、アップグレード余裕 1〜数ノードを見込むなら、/18はかなり窮屈です。(Microsoft Learn) - 新しい CIDR を選ぶ
新しい範囲は既存範囲を含むスーパーセットである必要があります。さらに、クラスター サブネット、ピアリング済み VNet、ExpressRoute、VPN、サービス CIDR と重複しないことが必須です。Pod CIDR には private IP 範囲の利用が推奨されており、公開 IP 範囲の利用はサポート外扱いです。(Microsoft Learn) - 変更を実行する
基本の更新コマンドは次の形です。(aka.ms)
az aks update \
--name <cluster-name> \
--resource-group <resource-group> \
--pod-cidr 10.244.0.0/16nncで反映を確認する
ネットワーク プロファイルに新しい CIDR が見えても、そこで完了判定しないのが実務上のコツです。Microsoft もNodeNetworkConfig(nnc) での確認を案内しています。(aka.ms)
kubectl get nnc -A -o jsonpath='{range .items[*]}{.metadata.name}{" "}{.status.networkContainers[0].subnetAddressSpace}{"\n"}{end}'- 拡張後の運用資料を更新する
監視しきい値、ノード上限、IP アドレス設計書、変更手順書まで更新してはじめて完了です。ここを後回しにすると、次の担当者がまた同じ計算をやり直すことになります。
IP 設計で見落としやすいポイント
Azure CNI Overlay の設計では、同じ仮想ネットワーク内の複数の独立した AKS クラスターで同じ pod CIDR 空間を使える一方、ピアリング先やオンプレミス接続先との重複は避ける必要があります。つまり、クラスター間の再利用はしやすいが、企業ネットワーク全体では重複により通信問題を起こしやすい、ということです。単一クラスターだけ見て CIDR を決めると失敗しやすいので、ExpressRoute・VPN・Hub-Spoke のアドレス計画まで含めて選ぶのが安全です。(Microsoft Learn)
失敗しやすいポイント
実務で特に多そうなのは、次の 4 つです。
- Node subnet の不足を Pod CIDR 拡張で解決しようとする
Pod CIDR 拡張で増えるのはポッド側の余地です。ノードは引き続き VNet サブネットの IP を使うので、ノード側サブネットの余裕やアップグレード用の空きが不足していると別の場所で詰まります。(Microsoft Learn) - 重複確認を VNet 内だけで済ませる
ピアリング、ExpressRoute、VPN、サービス CIDR まで見ないと、拡張後に通信経路の問題を招きます。(Microsoft Learn) - ポータル表示だけで完了判定する
ドキュメント上も、更新成功後にnncで実状態を確認するよう案内されています。(aka.ms) - 非 Overlay 環境で、移行・Cilium・CIDR 拡張を一度にやる
サポートされる順序と変更単位があるため、まとめて実施すると切り分けが難しくなります。(Microsoft Learn)
次にやるべきこと
AKS ポッド CIDR 拡張が GA に到達したことで、Azure CNI Overlay を使う Linux ベースの AKS クラスターでは、Pod IP 枯渇時の“再構築ありき”から一歩抜け出せるようになりました。特に、過去に小さめの pod CIDR を切ったクラスター、今後のノード増加が読みにくい共有基盤、継続運用を優先したいチームには実益が大きい機能です。(Microsoft)
まずやるべきことは 3 つです。今のクラスターが Azure CNI Overlay かどうかを確認すること、現在の pod CIDR が将来のノード数に足りるかを再計算すること、そして拡張候補の CIDR が周辺ネットワークと重複しないかを棚卸しすることです。すでに Overlay なら拡張計画を、まだ Overlay でなければ移行計画を先に進めるのが、今回の GA を最も実務に生かす動き方です。(Microsoft Learn)
コメント