Container Network Observabilityを理解するための前提
AKS networkingは変化が速いため、旧方式とcurrent recommendationを区別して記載しています。実装直前には下記Microsoft Learnのcurrent constraints / region / version supportを再確認してください。
Advanced Container Networking ServicesのContainer Network ObservabilityはCiliumとnon-Ciliumの両data planeで利用できるcurrent capability。 eBPFを利用してnode-level metricsとHubble metricsを提供し、DNS resolution、pod-to-pod、Service interactionなどを観測できる。
container network logsはsource/destination IP、pod/service、namespace、port、protocol等のflow metadataを記録し、allow/dropや通信主体の切り分けに使う。 Azure Monitor managed service for PrometheusとAzure Managed Grafanaへmetricsを統合でき、cluster-localだけでなくcentral monitoringへ持ち込める。
障害時だけtelemetryを見るのではなく、正常時のDNS latency、TCP reset/retransmit、drop rate、top talker等のbaselineを持つことが重要。 ログ量・retention・table plan・costはnetwork volumeに比例し得るため、stored logs/on-demand、aggregation、scopeを要件で使い分ける。
通信経路と責任境界
アドレスと識別情報の考え方
| Address / identity | Where it lives | 運用上の意味 |
|---|---|---|
| Pod/namespace | Kubernetes context | ephemeral IPだけでなくworkload metadataで検索できるようにする。 |
| Service | virtual frontend + backend set | Service-level symptomをactual Endpoint flowへ降ろす。 |
| Flow tuple | src/dst IP・port・protocol | 時刻とdecisionを固定して他logと相関する。 |
| DNS name | query/response/latency | FQDN policyやSaaS障害ではIP flowとDNS signalを結び付ける。 |
設計判断
| 判断軸 | 確認する問い | 設計として固定すること |
|---|---|---|
| Metrics vs logs | 常時計測と詳細調査をどう分けるか | SLO/alertはmetrics、who/why調査はflow logsを中心。 |
| Retention | 何日・どのscopeを保持するか | incident/regulatory requirementとcostから決定。 |
| Cardinality | pod/flow labelをどこまで保持するか | high-cardinalityを無制限にcentralizeしない。 |
| Cilium dependency | security機能も必要か | observability単体はnon-Ciliumでも利用可能。securityはCilium要件を別評価。 |
| Runbook | alertからどのqueryへ降りるか | DNS/drop/TCP/hot podごとに固定playbookを用意。 |
実装・移行の順序
- 正常clusterでnode/pod/TCP/DNS metricsと代表flowを採取しbaseline化する。
- DNS failure、policy drop、backend unavailable等のcontrolled fixtureでsignalを対応付ける。
- Azure Monitor/Prometheus/Grafanaのretention・workspace・RBACを設計する。
- alertからpod/namespace/service/flowへdrilldownするdashboard/queryを作る。
- incident runbookへKubernetes object snapshotとAzure route/NSG evidenceを併記する。
- 月次でingestion量と未使用metric/logをreviewし、costとsignal qualityを調整する。
運用で残しておく情報
| 観点 | 残すべき運用証拠 |
|---|---|
| DNS | query rate/error/latencyとsource workloadを確認。 |
| Drops | policy/forwarding dropをnamespace/pod/serviceで絞る。 |
| TCP | reset/retransmit/connection failuresをapplication symptomと時刻同期。 |
| Traffic balance | top talker/hot pod/uneven backend flowを確認。 |
変更前に確認する
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へ含める。
kubectl get pods -A -o wide
kubectl get svc,endpointslices -A
kubectl get networkpolicy -A
az aks show -g <rg> -n <cluster> --query "{dataplane:networkProfile.networkDataplane,plugin:networkProfile.networkPlugin}" -o jsoncCommon failure modes
| 症状 | 疑うboundary | 確認・是正 |
|---|---|---|
| dashboardは赤いが原因不明 | metricだけでflow context不足 | 該当時刻のnetwork logsへ降りsource/destination/port/decisionを確認。 |
| flow logsが多すぎる | scope/retention/cardinality過大 | stored/on-demandとaggregationを見直す。 |
| DNS errorのみ増加 | upstream/CoreDNS/policy/egress | DNS signalからsource namespaceを特定しquery pathを追う。 |
| non-Ciliumだから使えないと思い込む | observabilityとsecurity要件混同 | current docsではObservabilityはCilium/non-Cilium双方に対応。 |