Azure CNI Powered by Ciliumを理解するための前提
AKS networkingは変化が速いため、旧方式とcurrent recommendationを区別して記載しています。実装直前には下記Microsoft Learnのcurrent constraints / region / version supportを再確認してください。
Microsoftは2026年のcurrent guidanceでAzure CNI Powered by CiliumをAKSのrecommended and supported long-term networking configurationと位置付けている。 CiliumはeBPFを利用したAKS data planeで、Azure CNIのOverlayまたはVNet由来pod IP方式と組み合わせられる。
Azure CNI Powered by Cilium clusterではService routingをCiliumが担い、kube-proxyを使用しない。 CiliumにはNetworkPolicy engineが組み込まれ、別のAzure NPM/Calicoを必須としない。migrationでは既存engineがCiliumへ置換される場合がある。
current Microsoft LearnではAzure CNI Powered by CiliumはLinuxのみ。Windows nodeを必要とするclusterではこの制約を先に設計へ反映する。 hostNetwork podには通常のpod NetworkPolicyが適用されない点や、ipBlockでnode/pod IPをallowする際の制約など、policy semanticsを事前にtestする。
通信経路と責任境界
アドレスと識別情報の考え方
| Address / identity | Where it lives | 運用上の意味 |
|---|---|---|
| Pod IP | Azure CNI IPAMが供給 | Ciliumを採用してもOverlay/flatのIPAM choiceは別。 |
| Cilium identity | labels/namespace等からworkloadを識別 | policy selectionはIPだけでなくidentity semanticsを持つ。 |
| Service identity | Kubernetes Service/Endpoint | Cilium data planeがService routingを担う。 |
| Host identity | hostNetwork/node traffic | 通常podとpolicy boundaryが異なるため別レビュー。 |
設計判断
| 判断軸 | 確認する問い | 設計として固定すること |
|---|---|---|
| OS support | Windows nodeが必要か | 必要ならcurrent Cilium limitationを理由に別data plane/cluster splitを評価。 |
| Policy | Kubernetes NetworkPolicyだけか、FQDN/L7等ACNSが必要か | advanced security requirementがあればCilium + ACNSを評価。 |
| Migration | 既存Calico/Azure NPM policyとのsemantic差はないか | staging clusterでpolicy regression test。 |
| Performance | eBPF Host Routing等が必要か | 対応OS/feature conflictを確認し、通常Cilium migrationと別changeで評価。 |
| Observability | Hubble metrics/flow logsが必要か | ACNS observabilityはCilium/non-Cilium両方で使えるが、security機能はCilium前提。 |
実装・移行の順序
- 既存clusterのIPAM mode、network policy engine、OS/node pool構成をinventoryする。
- NetworkPolicy manifestを収集し、ipBlock/hostNetwork/特殊policy semanticsを洗い出す。
- supported migration pathでdata planeだけを変更し、IPAM changeと同時実施しない。
- canary workloadでDNS、Service、pod-to-pod、egress、ingress、deny/allow policyを再実行する。
- Cilium/ACNS telemetryでdrop/flowを確認し、既存iptables前提のoperational toolingを見直す。
- node rollout完了後に全node/podが期待data plane上にいることを確認する。
運用で残しておく情報
| 観点 | 残すべき運用証拠 |
|---|---|
| Profile | networkDataplaneがciliumか確認。 |
| Policies | NetworkPolicy/Cilium policyとselected endpointsを確認。 |
| Host networking | hostNetwork workloadを抽出し、policy boundary外としてレビュー。 |
| Node rollout | node OS/version/Cilium rollout差で局所障害がないか比較。 |
変更前に確認する
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,policy:networkProfile.networkPolicy}" -o jsonc
kubectl get nodes -o wide
kubectl get networkpolicy -A
kubectl get pods -A -o wideCommon failure modes
| 症状 | 疑うboundary | 確認・是正 |
|---|---|---|
| policy migration後に通信差 | Calico/Azure NPMとCiliumのsemantics差 | affected NetworkPolicyを最小fixtureで再現しselector/ipBlock/hostNetworkを確認。 |
| 一部nodeだけ異常 | rolling migration差 | node label/versionとpod placementを比較。 |
| hostNetwork podがpolicyを迂回 | current Cilium limitation | hostNetworkを別security controlで保護し、通常pod policyと混同しない。 |
| Windows workloadが載らない | Cilium Linux-only | cluster/node-pool architectureを再検討。 |