AKS Network Troubleshootingを理解するための前提
AKS networkingは変化が速いため、旧方式とcurrent recommendationを区別して記載しています。実装直前には下記Microsoft Learnのcurrent constraints / region / version supportを再確認してください。
最初に症状をDNS、connect timeout、connection refused、TLS/L7 error、policy drop、intermittent/packet lossへ分類すると調査branchが大きく減る。 Service障害ではService objectだけでなくEndpointSliceとpod readinessを確認する。backendが無ければAzure routeを調べても直らない。
same-pod/same-node/cross-node/externalの比較で、application、node dataplane、overlay/VNet、egress deviceのfailure domainを切り分ける。 Azure CNI Overlayではpod CIDR外のsourceがnode IPへSNATされるため、external firewall logでpod IPを探し続けない。
NetworkPolicy/ACNS securityを使う環境ではdeny event/flow logsをAzure NSG/Firewall logと同時刻で比較し、blocking layerを特定する。 private clusterのkubectl failureはworkload dataplane障害とは別。API FQDN DNS/management route/control-plane reachabilityを独立runbookで確認する。
通信経路と責任境界
アドレスと識別情報の考え方
| Address / identity | Where it lives | 運用上の意味 |
|---|---|---|
| Observed source | pod/node/NAT/edgeのどれか | network modeとSNAT stageごとにlog上のsourceが変わる。 |
| Observed destination | Service VIP/Endpoint/external IP/FQDN | 同じ「接続先」でも調査layerでaddressが変わる。 |
| Flow identity | 5-tuple + timestamp | 複数logを結ぶ最小キー。曖昧な「つながらない」を排除。 |
| Kubernetes identity | namespace/pod/service/labels | ephemeral IPをworkloadへ戻してpolicy/backend selectionを確認。 |
設計判断
| 判断軸 | 確認する問い | 設計として固定すること |
|---|---|---|
| DNSかIPか | IP直接で成功するか | DNS branchとtransport branchを分離。 |
| Serviceかpodか | pod IP直アクセスとService経由を比較 | Service routing/selector問題を分離。 |
| same-node/cross-node | 同一nodeだけ成功するか | inter-node/overlay/NSG問題を分離。 |
| internal/external | cluster/VNet内は成功するか | egress/ingress/NAT/Firewallへ範囲を絞る。 |
| policy on/off | policy対象だけ失敗するか | selector/deny evidenceを確認し、安易に全policy削除しない。 |
実装・移行の順序
- source pod、destination、protocol/port、timestamp、expected resultを固定する。
- kubectlでpod IP/node/readiness、Service、EndpointSlice、NetworkPolicyをsnapshotする。
- DNSならresolver→CoreDNS/NodeLocal DNS→upstreamの順でquery pathを確認する。
- pod IP直/Service、same-node/cross-nodeでfailure domainを狭める。
- az aks showでCNI/IPAM/dataplane/outboundTypeを確認し、そのmodelに沿ってAzure route/NSG/LB/NAT/Firewallを調べる。
- ACNS/Hubble/Firewall/NSG等のflow evidenceを時刻で突き合わせ、fix後に同じjourneyを再試験する。
運用で残しておく情報
| 観点 | 残すべき運用証拠 |
|---|---|
| Snapshot | kubectl get/describe結果をincident時刻付きで保存。 |
| Model | networkProfileを取得しOverlay/flat/Cilium/outboundTypeを誤認しない。 |
| Evidence | drop/flow/backend health/DNS metricを同じtime windowで収集。 |
| Retest | 修正後にoriginal 5-tupleとnegative controlを両方再実行。 |
変更前に確認する
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 pods -A -o wide
kubectl get svc,endpointslices -A -o wide
kubectl get networkpolicy -A
kubectl get events -A --sort-by=.lastTimestampCommon failure modes
| 症状 | 疑うboundary | 確認・是正 |
|---|---|---|
| timeout | route/NSG/Firewall/policy/drop | SYNの行き先とreturn pathをflow evidenceで追う。 |
| connection refused | destination到達済みだがlistener/backendなし | pod process/listening port/Service targetPortを確認。 |
| DNS SERVFAIL/timeout | CoreDNS/upstream/policy | resolver pathとDNS metrics/logsへ。 |
| intermittent | 一部backend/nodeだけ異常 | EndpointSliceとpod/node別成功率を比較。 |
| TLS/L7 | network到達後のSNI/cert/host/path/backend protocol | L3/L4成功を確認してからingress configへ。 |