Azure CNI: IPAM Modes and Designを理解するための前提
AKS networkingは変化が速いため、旧方式とcurrent recommendationを区別して記載しています。実装直前には下記Microsoft Learnのcurrent constraints / region / version supportを再確認してください。
Microsoftのcurrent pod-networking guidanceは一般的な選択としてAzure CNI Overlayを推奨する。direct pod IP accessが必要な場合はPod SubnetまたはNode Subnetを検討する。 Azure CNI OverlayではnodeだけがVNet subnet IPを消費し、podはcluster専用private CIDRを使う。
Pod Subnet系はpod IPをVNet空間から割り当て、direct pod reachabilityやVNet統合が必要な設計に使えるが、subnet capacityとIP lifecycleの管理が重要になる。 Node Subnet（legacy）はnodeとpodがnode subnetのaddress spaceを共有するため、大規模clusterではVNet IP consumptionが設計制約になりやすい。
IPAM modeとCilium data planeへの更新は独立した操作。両方を移行する場合は一度に変えず、別操作として実行する。 Kubenet clusterからCiliumへ直接data plane更新するのではなく、current Microsoft guidanceでは先にAzure CNI OverlayへIPAM migrationする経路が示されている。
通信経路と責任境界
アドレスと識別情報の考え方
| Address / identity | Where it lives | 運用上の意味 |
|---|---|---|
| Node Subnet | nodeとlegacy modeのpod capacityに影響 | subnet free IPだけでなくmaxPods・surge・scale-outを含める。 |
| Pod Subnet | podへVNet addressを供給 | direct pod reachabilityとIP scaleを要件から選ぶ。 |
| Overlay Pod CIDR | cluster-private address pool | VNet/on-prem/peeringと非重複。external通信ではsource translationを考慮。 |
| Data plane identity | Cilium等 | IPAM modeとは別。policy/Service forwarding semanticsを決める。 |
設計判断
| 判断軸 | 確認する問い | 設計として固定すること |
|---|---|---|
| 外部からpod IPへ直接到達 | 必要 / 不要 | 不要ならOverlayを優先。必要ならPod Subnet/Node Subnetを評価。 |
| IP scale | max nodes × maxPodsとupgrade surgeを含め何IP必要か | flat networkingではreserved/spare IPを含めsubnet sizing。Overlayでもpod CIDR sizing。 |
| On-prem reachability | pod prefixをon-premへroute/advertiseする必要があるか | Overlayはpodをnode sourceへSNATする設計が基本。direct pod IP要件はflat modeで検討。 |
| Data plane | Cilium機能が必要か | IPAMと切り離して選定。Cilium migrationは別change。 |
| Windows | Windows node poolが必要か | Ciliumのcurrent Linux-only制約を考慮。 |
実装・移行の順序
- workload数、maxPods、autoscale、surge、将来cluster数からaddress budgetを算出する。
- on-prem/peering/private endpoint CIDRと重複しないpod/service/node rangeを予約する。
- direct pod IP requirementを証拠付きで確認し、無ければOverlayをdefault候補にする。
- data planeは別decisionとしてCilium要件を評価する。
- migration時はsupported pathとnode rolloutを確認し、IPAM/data planeを別waveで変更する。
- 実装後、pod IP source・source IP preservation/SNAT・route/NSG・Service connectivityを検証する。
運用で残しておく情報
| 観点 | 残すべき運用証拠 |
|---|---|
| Network profile | networkPlugin / networkPluginMode / networkDataplane / podCidr(s) / serviceCidr(s)を記録。 |
| Capacity | node subnet available IPとcluster autoscaler/upgrade surge分を確認。 |
| Route domain | pod prefixがVNet route tableで見える前提か、overlay internal routeかを区別。 |
| Migration | 実施前後のnetworkProfileとnode image/version、接続中session影響を記録。 |
変更前に確認する
Control state
AKS networkProfile、Kubernetes object、Azure associationをread-onlyで採取し、desired configurationを固定する。
Data plane
同じ5-tupleで実通信し、forward path・return path・source translation・policy decisionを証明する。
Observability
DNS/TCP/flow/drop/backend health等、障害点に対応するsignalを同一時刻で収集する。
Negative test
allowだけでなく、禁止すべき通信が明示的に失敗することもsecurity acceptanceへ含める。
az aks show -g <rg> -n <cluster> --query "{plugin:networkProfile.networkPlugin,mode:networkProfile.networkPluginMode,dataplane:networkProfile.networkDataplane,podCidrs:networkProfile.podCidrs,serviceCidrs:networkProfile.serviceCidrs}" -o jsonc
kubectl get nodes -o wide
kubectl get pods -A -o wideCommon failure modes
| 症状 | 疑うboundary | 確認・是正 |
|---|---|---|
| subnet IP枯渇 | flat modeのpod reservation、surge、scale-out | current node/pod countだけでなくmaxPodsとupgrade capacityから再計算。 |
| on-prem prefixとpod CIDR競合 | 重複address plan | overlapはroute ambiguityを生むためrenumber/NAT等のdesign correctionが必要。 |
| migration後一部podだけ失敗 | node pool rollout差、policy engine change | podが載るnode generationとCNI/Cilium状態を比較。 |
| Azure routeにpod prefixが無い | Overlayなのにflat networking前提で調査 | Overlayのroute domainとSNAT modelへ切り替えてpacket walk。 |