AKS Networking Overview

この記事の目次

要点 Packet path Address 設計判断実装順序運用確認障害変更安全 Sources

AKS Networking Overviewを理解するための前提

AKS networkingは変化が速いため、旧方式とcurrent recommendationを区別して記載しています。実装直前には下記Microsoft Learnのcurrent constraints / region / version supportを再確認してください。

2026年9月時点のMicrosoft guidanceでは、一般的なpod networkingの第一候補はAzure CNI Overlay。direct pod IP reachabilityが必要な場合にPod Subnet/Node Subnet系を検討する。 IPAM modeとdata planeは別の設計軸。Overlay / Node Subnet / Pod Subnetはpod IPの割当・到達性を決め、Cilium / Azure iptables等はnode上でpacket forwarding・Service routing・policy enforcementを担う。

Azure CNI Powered by Ciliumを使うclusterではKubernetes Service routingにkube-proxyを使わず、Cilium dataplaneが処理する。 Service CIDR、pod CIDR、node subnet、peered VNet、on-premises networkの重複は障害時に極めて切り分けにくい。cluster作成前に一枚のaddress mapへ統合する。

Ingressとegressは別経路として設計する。LoadBalancer/Layer7 ingressを作っても、pod/nodeのoutbound path、SNAT public IP、AKS依存先への到達性は決まらない。障害調査では「Pod → Service VIP/Endpoint → node dataplane → node subnet → UDR/NSG/NAT/Firewall → destination」と逆方向return pathを同じ5-tupleで追う。

通信経路と責任境界

Workload

Pod IP / namespace / NetworkPolicy

application socketを起点にする

Cluster dataplane

CiliumまたはAzure dataplane

Service translation、policy、node routing

Azure node subnet

NIC / NSG / UDR

VNet routingとsecurity boundary

Edge

LB / NAT Gateway / Firewall / AGfC

internet・on-prem・private serviceへ接続

調査原則: Kubernetes objectが正しいことはAzure data pathの正常性を保証せず、Azure resourceがHealthyであることもpod-to-pod/pod-to-serviceの成功を保証しません。source・destination・protocol・port・時刻を固定して両layerを照合します。

アドレスと識別情報の考え方

Address / identity	Where it lives	運用上の意味
Node IP	node subnet/VNet address	Azure route・NSG・egressのanchor。pod sourceとは別にinventoryする。
Pod IP	Overlay CIDRまたはVNet由来	CNI IPAM modeで意味が変わる。external側で常に見えるとは限らない。
Service IP	Service CIDR内virtual IP	VNet NICのIPではない。EndpointSlice/backendへcluster dataplaneが転送する。
Ingress/Egress IP	LB/AGfC/NAT/Firewall等	client-facing identityとoutbound source identityを別々に管理する。

重要: IPアドレスそのものとworkload/service identityを混同しません。autoscale・reschedule・SNAT・load balancingでaddressは変化するため、Kubernetes metadataとAzure resource identityを合わせて記録します。

設計判断

判断軸	確認する問い	設計として固定すること
Pod IP model	pod IPをVNetから直接割り当てる必要があるか。外部からpod IPへ直接routeする要件があるか。	Overlayをdefault候補。direct pod IP requirementがある場合だけPod Subnet/Node Subnetを選定。
Data plane	NetworkPolicy、scale、ACNS security/observability、Windows node要件は何か。	Linux中心で長期運用ならCiliumを優先検討。Windowsを含む場合は制約を先に確認。
Ingress	HTTP-likeかTCP/UDPか。TLS termination、Gateway API、WAF/managed L7が必要か。	HTTP-likeはmanaged L7/Gateway API、非HTTPはLoadBalancer Serviceを基準に選定。
Egress	固定public IP、central inspection、network isolation、SNAT scaleのどれが必要か。	outboundTypeとUDR/NAT/Firewallをセットで設計。
Control plane	public API endpointを許可するか。運用端末はどこからkubectlするか。	private cluster/API server VNet integrationのDNSとmanagement pathまで設計。
Security/Telemetry	default-deny、FQDN/L7 policy、flow visibility、DNS troubleshootingが必要か。	NetworkPolicyとACNS observability/securityを初期設計へ。

実装・移行の順序

node subnet / pod CIDR / Service CIDR / DNS service IP / peered/on-prem CIDRを重複なく確定する。
IPAM modeとdata planeを別々に決定し、networkProfileとして設計記録へ残す。
ingress、egress、API server accessの3つのnorth-south pathをtraffic matrixへ記載する。
namespace間・pod間east-westのallow/deny policyとDNS dependencyを定義する。
非本番clusterでsource podから代表destinationまでpacket walkし、Azure側effective route/NSGも照合する。
observabilityを有効化し、正常時のDNS/TCP/drop/flow baselineを残してから本番展開する。

運用で残しておく情報

観点	残すべき運用証拠
Cluster profile	az aks showでnetworkPlugin/networkPluginMode/networkDataplane/outboundType/serviceCidr/dnsServiceIpを記録する。
Kubernetes objects	pod IP、node、Service type/VIP、EndpointSlice、NetworkPolicyを同時刻で採取する。
Azure path	node subnetのroute table、NSG、NAT/Firewall/LB関連を確認する。
Name resolution	Pod内のresolv.confとCoreDNS/NodeLocal DNS構成、query resultを確認する。

変更前に確認する

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へ含める。

Read-only / discovery commands

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,endpointslices -A
kubectl get networkpolicy -A

Common failure modes

症状	疑うboundary	確認・是正
Pod同士だけ通信不可	NetworkPolicy、Cilium identity/policy、pod CIDR/NSG	同一node/別nodeを分け、policy有無とpod CIDR pathを確認。
Service VIPだけ失敗	EndpointSlice不整合、Service selector、dataplane	EndpointSlice→backend pod直アクセス→Serviceの順で比較。
外部だけ失敗	outboundType、UDR、Firewall/NAT、AKS required egress	node subnetからのdefault routeとSNAT sourceを確認。
kubectlだけ失敗	private API/DNS/peering/VPN	API FQDNの名前解決とmanagement clientからprivate endpointまでを分離。
DNSだけ失敗	CoreDNS/NodeLocal DNS/upstream DNS/policy	名前解決先を段階分解しUDP/TCP 53とupstream responseを確認。

Change safety / rollback

一括変更を避ける: cluster networkingの変更はnode replacementや接続断を伴う可能性がある。IPAM modeとdata planeを同時に変えず、supported migration pathを確認し、canary node pool/maintenance window/rollback条件を明示する。

AKS Networking Overviewを理解するための前提

通信経路と責任境界

アドレスと識別情報の考え方

設計判断

実装・移行の順序

運用で残しておく情報

変更前に確認する

Control state

Data plane

Observability

Negative test

Common failure modes

Change safety / rollback

Related articles

Official sources