Azure CNI Overlayを理解するための前提
AKS networkingは変化が速いため、旧方式とcurrent recommendationを区別して記載しています。実装直前には下記Microsoft Learnのcurrent constraints / region / version supportを再確認してください。
Overlayではcluster nodeだけがVNet subnetからIPを取得し、podはcluster作成時に指定したprivate pod CIDRからIPを取得する。 Microsoft Learnは各nodeへpod CIDRから/24 address spaceを割り当てるmodelを説明している。scale-out nodeにも同じcluster pod CIDRからaddress spaceが供給される。
podからpod CIDR外のdestinationへ出るtrafficはnode IPへSNATされる。外部側では通常pod IPではなくnode sourceとして見える。 pod CIDRはnode subnetだけでなく、VNet peering、ExpressRoute、VPNなどdirectly connected networkのprefixとも重複させない。
Overlay pod-to-pod trafficはencapsulation tunnelを前提としないAzure networking stack上の別routing domainで処理される。 subnet NSGはOverlay trafficへ影響するため、Node CIDR↔Pod CIDR / Pod CIDR↔Pod CIDRなどcluster機能に必要なtrafficを誤ってdenyしない。
通信経路と責任境界
アドレスと識別情報の考え方
| Address / identity | Where it lives | 運用上の意味 |
|---|---|---|
| Node CIDR | VNet subnet address | Azure-facing source/next-hop anchor。 |
| Pod CIDR | cluster-private overlay range | nodeごとのpod block供給元。connected networkと非重複必須。 |
| Service CIDR | cluster virtual-service range | pod/node/on-prem/VNetと重複させない。 |
| External source | 通常node IPへSNAT | pod CIDR外destination側のallowlist/flow logはnode source前提で確認。 |
設計判断
| 判断軸 | 確認する問い | 設計として固定すること |
|---|---|---|
| Pod CIDR size | 何node × /24 allocationを将来必要とするか | current node数ではなくmax scaleを基準にcluster pod CIDRを確保。 |
| CIDR uniqueness | peered/on-prem/other clusterと重複しないか | IPAMで全体予約し、再利用はrouting domainが交差しない場合だけ。 |
| NSG | node/pod internal flowをどこで制御するか | subnet NSGはplatform guardrail、workload segmentationはNetworkPolicyを優先。 |
| External source identity | external側でpod IP識別が必要か | Overlay SNATで要件を満たさない場合は別IPAM mode/egress identityを検討。 |
| Dual-stack | IPv6要件とegress方式は何か | pod/service CIDRsとNAT optionのcurrent supportを事前検証。 |
実装・移行の順序
- cluster pod CIDR、service CIDR、node subnet、hybrid/peering prefixのnon-overlapを機械的に検査する。
- max node countからpod CIDR capacityを算出し、nodeごとの/24 allocationを前提に余裕を持たせる。
- node subnet NSGでrequired node/pod flowを遮断していないことを確認する。
- 代表pod間をsame-node/cross-nodeで試験し、Service経由も追加する。
- pod→VNet/on-prem/internetでdestination側が見るsource IPを記録し、SNAT expectationと照合する。
- NetworkPolicyを導入し、Azure NSGと責任分界を明確にする。
運用で残しておく情報
| 観点 | 残すべき運用証拠 |
|---|---|
| CIDR inventory | podCidr(s)、serviceCidr(s)、nodeSubnet ID、peering/on-prem prefixを一枚にする。 |
| Node allocation | node追加前後でpod placementとnode scaleを確認。 |
| Source identity | external destination側でsourceがnode IPになることを検証。 |
| NSG | deny追加時はpod↔pod、node↔pod、DNS、Service trafficをcanary検証。 |
変更前に確認する
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 networkProfile -o jsonc
kubectl get nodes -o wide
kubectl get pods -A -o wide
kubectl get svc -A -o wideCommon failure modes
| 症状 | 疑うboundary | 確認・是正 |
|---|---|---|
| 外部hostへ届かない | pod CIDRが外部prefixと重複 | Microsoft guidance通りnon-overlapを確認。overlap時はoverlayへ吸われる経路を疑う。 |
| cross-node podだけ失敗 | NSG/overlay dataplane/node health | same-node比較後、Node CIDR↔Pod CIDRとPod CIDR↔Pod CIDRを確認。 |
| source IPがpodでない | Overlayの正常SNAT behavior | node IP sourceが設計通りか確認し、必要ならegress identityを設計。 |
| scale-out失敗 | pod CIDR/node subnet capacity | node subnet IPとoverlay pod CIDRの両方を別々に確認。 |