結論から言うと、AKSの Azure CNI Powered by Cilium は、Azure CNIのIPアドレス管理やAzure側の制御面を使いながら、データプレーンにCiliumを採用するネットワーク構成です。新規クラスターでは --network-dataplane cilium を指定して作成し、既存クラスターではネットワーク方式、Windowsノード、NetworkPolicy、移行時のノード再イメージ化を事前に確認する必要があります。特に、既存環境からの移行は単なるオプション追加ではなく、ネットワーク設計と運用手順に影響する変更として扱うべきです。(Microsoft Learn)
Azure Kubernetes ServiceでCiliumを使うメリットは、eBPFを活用した効率的なサービスルーティング、ネットワークポリシー適用、トラフィック可視化、大規模クラスター対応にあります。一方で、Linux限定、ipBlock の扱い、Cilium設定のカスタマイズ制限、ACNSが必要な機能など、見落とすと本番展開でつまずきやすいポイントもあります。この記事では、2026年5月時点の公式情報をもとに、管理者・開発者が確認すべき変更点、設定、移行時の注意点を整理します。(Microsoft Learn)
AKSのAzure CNI Powered by Ciliumは何が変わるのか
Azure CNI Powered by Ciliumは、Azure Container Networking Interfaceのコントロールプレーンと、Ciliumのデータプレーンを組み合わせたAKS向けのネットワーク構成です。従来のAzure CNIやAzure CNI Overlayの考え方を引き継ぎながら、Ciliumによるネットワークポリシー適用やeBPFベースの通信処理を利用できます。(Microsoft Learn)
実務上の変更点は、次のように整理できます。
| 観点 | 変わること | 管理者・開発者が見るべきポイント |
|---|---|---|
| データプレーン | Ciliumをデータプレーンとして利用 | --network-dataplane cilium を指定して作成・更新する |
| NetworkPolicy | Ciliumがポリシーを適用 | Azure Network Policy ManagerやCalico前提の挙動を見直す |
| IPアドレス管理 | Overlay、VNet、Node Subnetの選択肢がある | Pod CIDR、VNet、サブネット設計を事前に決める |
| kube-proxy | Ciliumデータプレーンのクラスターではkube-proxyを使わない | 既存の運用監視やトラブルシュート手順を更新する |
| 高度な機能 | FQDN FilteringやL7 PolicyなどはACNSが関係 | 必要機能が標準構成だけで使えるか確認する |
重要なのは、Ciliumを入れることで「通信が速くなりそう」という単純な話ではない点です。NetworkPolicyの評価方法、Pod間通信の許可条件、DNSやFQDN制御、可視化の方法まで変わる可能性があります。
対象者と影響範囲
Azure CNI Powered by Ciliumの影響は、AKSクラスターを作る担当者だけに限られません。ネットワーク、セキュリティ、アプリケーション開発、SREのそれぞれに確認項目があります。
| 対象者 | 主な影響 | 確認すべきこと |
|---|---|---|
| AKS管理者 | クラスター作成・更新方法が変わる | Azure CLIバージョン、ネットワーク方式、ノードプール構成 |
| ネットワーク担当者 | Pod IP、VNet、サブネット設計に影響 | Overlayを使うか、VNet上のPod IPを使うか |
| セキュリティ担当者 | NetworkPolicyの実装基盤がCiliumになる | L3/L4、FQDN、L7ポリシーの使い分け |
| アプリ開発者 | Pod間通信や外部通信の許可条件に影響 | ipBlock ではなくラベルベースの設計が必要な場面 |
| SRE・運用担当者 | 障害調査や監視観点が変わる | Cilium、ACNS、Flow Logs、メトリクスの確認方法 |
特に既存クラスターを移行する場合は、ネットワークポリシーの互換性だけでなく、更新時のノード再イメージ化による影響も考慮する必要があります。Microsoftの移行ガイドでは、データプレーン更新時にノードプールが同時に再イメージ化され、影響はノードイメージ更新やKubernetesバージョンアップに近いと説明されています。(Microsoft Learn)
新規AKSクラスターで選べる3つのIP割り当て方式
Azure CNI Powered by Ciliumでは、Pod IPの割り当て方法として複数の構成が用意されています。選択を誤ると、後からVNetのアドレス不足や通信制御の複雑化につながるため、クラスター作成前に決めておくことが重要です。
| 方式 | 概要 | 向いているケース | 注意点 |
|---|---|---|---|
| Overlay network | Pod IPをOverlayネットワークから割り当てる | VNetのIP消費を抑えたい、大規模化を見込む | Pod CIDRが既存ネットワークと重複しないようにする |
| Virtual network | Pod IPをVNet上のPod用サブネットから割り当てる | Azureネットワーク設計とPod IPを明確に分けたい | ノード用・Pod用サブネットの設計が必要 |
| Node Subnet | Node SubnetからIPを割り当てる構成 | シンプルな構成で開始したい | Azure CLI 2.69.0以降が必要 |
公式ドキュメントでは、新規作成時の前提としてAzure CLI 2.48.1以降が必要とされています。また、Node Subnet方式を使う場合はAzure CLI 2.69.0以降が必要です。(Microsoft Learn)
Overlay networkで作成する例
Overlayを使う場合は、--network-plugin-mode overlay と --network-dataplane cilium を指定します。
az aks create \
--name <clusterName> \
--resource-group <resourceGroupName> \
--location <location> \
--network-plugin azure \
--network-plugin-mode overlay \
--pod-cidr 192.168.0.0/16 \
--network-dataplane cilium \
--generate-ssh-keysここで注意したいのは、--pod-cidr の範囲です。既存のVNet、サービスCIDR、接続先ネットワークと重複すると、移行後や拡張時に通信トラブルの原因になります。検証環境では動いても、VPNやExpressRoute、他システムとの接続で問題が出ることがあります。
VNet上のPod用サブネットを使う例
VNetにノード用サブネットとPod用サブネットを作り、AKS作成時にそれぞれ指定します。
az group create \
--name <resourceGroupName> \
--location <location>
az network vnet create \
--resource-group <resourceGroupName> \
--location <location> \
--name <vnetName> \
--address-prefixes 10.0.0.0/8
az network vnet subnet create \
--resource-group <resourceGroupName> \
--vnet-name <vnetName> \
--name nodesubnet \
--address-prefixes 10.240.0.0/16
az network vnet subnet create \
--resource-group <resourceGroupName> \
--vnet-name <vnetName> \
--name podsubnet \
--address-prefixes 10.241.0.0/16AKS作成時には、ノード用サブネットとPod用サブネットを指定します。
az aks create \
--name <clusterName> \
--resource-group <resourceGroupName> \
--location <location> \
--max-pods 250 \
--network-plugin azure \
--vnet-subnet-id /subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/virtualNetworks/<vnetName>/subnets/nodesubnet \
--pod-subnet-id /subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/virtualNetworks/<vnetName>/subnets/podsubnet \
--network-dataplane cilium \
--generate-ssh-keysこの方式では、Pod用サブネットのサイズ見積もりが重要です。将来のノード数、Pod数、オートスケール、ステージング環境の追加まで考慮しておかないと、IP不足がボトルネックになります。
Node Subnetで作成する例
Node SubnetからIPを割り当てる場合は、次のように作成できます。
az aks create \
--name <clusterName> \
--resource-group <resourceGroupName> \
--location <location> \
--network-plugin azure \
--network-dataplane cilium \
--generate-ssh-keysシンプルに見えますが、本番環境では「後からOverlayへ移行するか」「既存のVNetアドレス計画に余裕があるか」を事前に確認しておくべきです。
対応するKubernetesバージョンとCiliumの最低バージョン
公式ドキュメントでは、Kubernetesバージョンごとの最低Ciliumバージョンが示されています。AKSのアップグレード計画を立てるときは、KubernetesだけでなくCilium側のバージョンも確認してください。(Microsoft Learn)
| Kubernetesバージョン | 最低Ciliumバージョン |
|---|---|
| 1.29 LTS | 1.14.20 |
| 1.30 LTS | 1.14.20 |
| 1.31 LTS | 1.16.16 |
| 1.32 | 1.17.9 |
| 1.33 | 1.17.9 |
| 1.34 | 1.18.6 |
| 1.35 | 1.18.6 |
アップグレード時に見るべきポイントは、単に「Kubernetesを上げられるか」ではありません。NetworkPolicy、Cilium Endpoint Slices、ACNS機能、監視設定がアップグレード後も期待どおり動くかを、検証クラスターで確認することが重要です。
NetworkPolicyで注意すべき変更点
Azure CNI Powered by Ciliumでは、CiliumがNetworkPolicyを適用します。Ciliumを使う場合、Azure Network Policy ManagerやCalicoのような別のネットワークポリシーエンジンを追加で入れる必要はありません。L3/L4の CiliumNetworkPolicy はKubernetesの NetworkPolicy と併用でき、CiliumClusterwideNetworkPolicy もサポートされています。(Microsoft Learn)
ただし、既存のNetworkPolicyをそのまま移行できるとは限りません。特に注意が必要なのは ipBlock です。
公式FAQでは、Azure CNI Powered by Ciliumの制限として、NetworkPolicy の ipBlock でPod IPやNode IPへのアクセス許可を表現できないと説明されています。たとえば 0.0.0.0/0 を許可しても、Pod IPやNode IPへの通信はブロックされる可能性があります。Podを選択したい場合は、namespaceSelector や podSelector を使う設計に変更する必要があります。(Microsoft Learn)
ipBlock に頼らない設計例
外部サービスへのEgressを許可しつつ、クラスター内Podとの通信も許可したい場合は、次のような考え方が必要です。
| やりたいこと | 避けたい設計 | 推奨される考え方 |
|---|---|---|
| 外部インターネット宛てを許可 | ipBlock: 0.0.0.0/0 だけで全通信を許可したつもりになる | 外部向けCIDRとPod選択条件を分ける |
| 同一Namespace内のPod通信を許可 | Pod IPの範囲をCIDRで許可する | podSelector を使う |
| 複数Namespace間の通信を許可 | NamespaceごとのIP範囲を管理する | namespaceSelector とラベルを使う |
| Node IP宛て通信を許可 | ipBlock でNode IPを許可する | 仕様上の制限を前提に設計を見直す |
また、spec.hostNetwork: true を使うPodにはNetworkPolicyが適用されません。これは、hostNetworkを使うPodが個別のPod IDではなくホスト側のIDとして扱われるためです。監視エージェント、DaemonSet、特殊なネットワーク系コンポーネントを使っている場合は、hostNetworkの有無を棚卸ししてください。(Microsoft Learn)
ACNSが必要になる機能を確認する
Azure CNI Powered by Ciliumを有効にしただけで、Cilium関連のすべての高度機能が使えるわけではありません。FQDN Filtering、L7 Network Policy、Container Network Observabilityなどを使う場合は、Advanced Container Networking Services、つまりACNSの有効化を検討する必要があります。(Microsoft Learn)
| 機能 | ACNSなし | ACNSあり |
|---|---|---|
| Kubernetes NetworkPolicy | 利用可 | 利用可 |
| Local Redirect Policy | 利用可 | 利用可 |
| Cilium L3/L4 NetworkPolicy | 利用可 | 利用可 |
| Cilium Clusterwide NetworkPolicy | 利用可 | 利用可 |
| FQDN Filtering | 利用不可 | 利用可 |
| L7 NetworkPolicy | 利用不可 | 利用可 |
| Container Network Observability | 利用不可 | 利用可 |
| WireGuard | 利用不可 | 利用可 |
| mTLS Encryption | 利用不可 | 利用可 |
| eBPF Host Routing | 利用不可 | 利用可 |
判断基準は明確です。単にPod間通信をL3/L4で制御したいなら、標準のCilium NetworkPolicyで足りる場合があります。一方、外部SaaSへの通信をFQDNで制御したい、HTTPやgRPCレベルでポリシーを分けたい、Flow Logsで通信を可視化したい場合は、ACNSを前提に設計すべきです。
Local Redirect PolicyとDNSまわりの注意点
Local Redirect Policyは、Kubernetes v1.29以降でサポートされます。ACNSのFQDN Filteringと組み合わせる場合、Cilium Network PolicyのEgressラベルがNode Local DNS CacheのPodラベルと一致している必要があります。DNSまわりの設定は見落とされやすく、名前解決だけ失敗する、特定のNamespaceだけ外部通信できない、といった障害につながることがあります。(Microsoft Learn)
特に注意したいのは、AKS Local DNSとACNSのFQDN Filteringが互換ではないとされている点です。FQDNベースのEgress制御を導入する場合は、DNSキャッシュ、CoreDNS、Node Local DNS Cache、ACNSの組み合わせを検証環境で確認してください。(Microsoft Learn)
既存AKSクラスターを移行する前の確認ポイント
既存クラスターにAzure CNI Powered by Ciliumを適用する場合は、新規作成よりも慎重な確認が必要です。Microsoftの移行ガイドでは、既存AKSクラスターのネットワーク移行について、Azure CNI Overlayへの単一方向の移行パスが示されています。移行後にNode Subnetベースのネットワーク方式へ戻すことはできません。(Microsoft Learn)
| 確認項目 | 内容 | 見落とした場合のリスク |
|---|---|---|
| 現在のネットワーク方式 | Azure CNI、Kubenet、Node Subnet、Overlayのどれか | サポートされない移行手順を選んでしまう |
| IPAMとデータプレーン | 同時に更新できないケースがある | 更新コマンドが失敗する、手順を戻せない |
| Windowsノードプール | Ciliumデータプレーン更新はWindowsノードプールで非サポート | 本番クラスターを更新できない |
| 既存NetworkPolicy | NPMやCalicoからCiliumへ置き換わる | 通信許可・拒否の挙動が変わる |
| Node Auto-Provisioning | NAP有効クラスターはそのまま更新できない | 更新前にNAP無効化が必要 |
| ノード再イメージ化 | 更新時にノードプールが再イメージ化される | 一時的な通信影響やPod再配置が発生する |
| Pod CIDR | VNetやService CIDRと重複しないか | 移行後に通信できない範囲が出る |
| ip-masq-agent | カスタム設定や古いConfigMapの有無 | 特定IP範囲への接続が切れる |
既存クラスターでAzure CNI OverlayとCiliumの両方へ移行する場合、IPAMモードとデータプレーンを一度に更新するのではなく、まずAzure CNI Overlayへ更新し、その後にAzure CNI Powered by Ciliumへ更新する手順が必要です。(Microsoft Learn)
移行の実務手順
本番環境では、次の順序で進めると失敗を減らせます。
- 現在のAKSクラスター構成を棚卸しする
- Windowsノード、NAP、NetworkPolicy、Pod CIDR、ip-masq-agent設定を確認する
- 検証用クラスターでNetworkPolicyと主要アプリの通信を再現する
- 必要であれば先にAzure CNI Overlayへ移行する
- 別操作として
--network-dataplane ciliumを適用する - Cilium Pod、NetworkPolicy、DNS、外部Egress、Ingressを確認する
- ロールバックではなく、Blue/Greenや新クラスター切り替えを前提に復旧計画を用意する
移行後にOverlayからNode Subnetへ戻せない点を考えると、「問題が出たら元に戻す」ではなく、「問題が出たら旧クラスターへトラフィックを戻す」設計のほうが現実的です。
展開後に確認すべきコマンド
Azure CNI Powered by Ciliumを展開したら、作成できたかどうかだけでなく、Ciliumが期待どおり動作しているかを確認します。
az --versionAzure CLIのバージョンを確認します。新規作成では2.48.1以降、Node Subnet方式では2.69.0以降が必要です。(Microsoft Learn)
az aks show \
--resource-group <resourceGroupName> \
--name <clusterName> \
--query networkProfileAKSのネットワークプロファイルを確認します。networkPlugin、networkPluginMode、networkDataplane、Pod CIDRなどをチェックします。
kubectl -n kube-system get pods -l k8s-app=cilium -o wideCiliumのPodが各ノードで動いているか確認します。
kubectl -n kube-system get daemonset ciliumCilium DaemonSetの起動数、READY数、AVAILABLE数を見ます。ノード数と一致しない場合は、ノード状態、taint、リソース不足、Cilium Podのイベントを確認します。
kubectl get networkpolicy -A
kubectl get ciliumnetworkpolicy -A
kubectl get ciliumclusterwidenetworkpolicy既存のKubernetes NetworkPolicyとCilium系ポリシーを確認します。移行後は、以前のNPMやCalico前提のポリシーが意図どおり動いているか、Namespace単位で通信テストを行ってください。
kubectl get pods -A \
-o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,HOSTNETWORK:.spec.hostNetworkhostNetworkを使うPodを確認します。hostNetwork PodにはNetworkPolicyが適用されないため、セキュリティ上の例外として扱う必要があります。
よくある失敗と対策
Azure CNI Powered by Ciliumでよくある失敗は、Ciliumそのものの理解不足よりも、既存のネットワーク設計をそのまま持ち込むことです。
| 失敗しやすいポイント | 起きること | 対策 |
|---|---|---|
--enable-ebpf-dataplane を使う | 古い手順に依存する | 現行の --network-dataplane cilium を使う |
ipBlock でPod IPを許可する | Pod間通信が意図せずブロックされる | namespaceSelector と podSelector を使う |
| ACNSなしでFQDN制御を期待する | FQDN Filteringが使えない | ACNSの有効化を検討する |
| hostNetwork Podを見落とす | NetworkPolicyが適用されないPodが残る | hostNetwork利用Podを棚卸しする |
| Cilium ConfigMapを自由に変更しようとする | サポート外の変更になる | AKS管理下であることを前提にする |
| 高頻度に作成・削除されるJobのラベルを放置する | Cilium identityが増えやすい | Sparkなどは不要ラベル除外を検討する |
| Windowsノードを含む既存クラスターで更新する | データプレーン更新ができない | Linuxクラスターまたは新規構成を検討する |
Cilium ConfigMapについては、AKSが管理しており、原則として自由なカスタマイズはできません。公式FAQでは、kube-system 名前空間の cilium-config において、ラベル除外のみがサポートされると説明されています。高頻度にPodが入れ替わるSparkジョブのようなワークロードでは、!spark-app-name や !spark-app-selector のようなラベル除外を検討することで、Cilium identityの増加を抑えられる場合があります。(Microsoft Learn)
開発者がNetworkPolicy設計で意識すべきこと
アプリケーション開発者は、Cilium導入を「インフラ側の変更」とだけ捉えないほうがよいです。マイクロサービス間通信、外部API通信、DNS、Namespace分離の設計に直接関係します。
たとえば、決済APIへ外部通信するPodと、社内APIへ通信するPodを分けたい場合、単純にIPアドレスで制御するよりも、Namespace、ServiceAccount、Podラベルを使った設計のほうが運用しやすくなります。CiliumではL3/L4のポリシーだけでなく、ACNSを組み合わせることでFQDNやL7レベルの制御も検討できます。(Microsoft Learn)
設計時は、次の観点でポリシーを分けると整理しやすくなります。
| 通信パターン | 設計の考え方 |
|---|---|
| 同一アプリ内のPod間通信 | Podラベルで許可する |
| Namespaceをまたぐ通信 | NamespaceラベルとPodラベルを組み合わせる |
| 外部SaaSへの通信 | CIDRまたはACNSによるFQDN制御を検討する |
| 管理系DaemonSetの通信 | hostNetworkや特権設定の有無を確認する |
| DNS通信 | CoreDNS、Node Local DNS Cache、FQDN Filteringの関係を確認する |
開発者が特に避けるべきなのは、「IPが分かっているから許可する」という設計です。KubernetesではPod IPが変わりやすく、CiliumでもラベルやIDベースの考え方を使うほうが、変更に強い構成になります。
Dual-stack構成でのポイント
Azure CNI Powered by Ciliumでは、Dual-stack AKSクラスターも構成できます。公式ドキュメントでは、Kubernetes 1.29以上が必要で、IPv6トラフィックもCilium Network Policyエンジンで制御できると説明されています。(Microsoft Learn)
Overlay構成でDual-stackを使う場合は、--ip-families ipv4,ipv6 を指定します。
az aks create \
--name <clusterName> \
--resource-group <resourceGroupName> \
--location <location> \
--network-plugin azure \
--network-plugin-mode overlay \
--network-dataplane cilium \
--ip-families ipv4,ipv6 \
--generate-ssh-keysDual-stackは将来性のある構成ですが、既存のIngress、Service、外部ロードバランサー、監視ツール、NetworkPolicyがIPv6に対応しているかを確認する必要があります。IPv4だけで動作確認しているアプリをそのままDual-stack化すると、名前解決やEgress制御で想定外の通信経路が発生することがあります。
本番導入前のチェックリスト
最後に、AKSでAzure CNI Powered by Ciliumを使う前に確認すべき項目をまとめます。
| チェック項目 | 確認内容 |
|---|---|
| Azure CLI | 2.48.1以降か。Node Subnet方式なら2.69.0以降か |
| Kubernetesバージョン | Ciliumの最低バージョン表と整合しているか |
| ノードOS | Linux前提で設計しているか |
| Windowsノード | 既存クラスター更新時に含まれていないか |
| IPAM方式 | Overlay、VNet、Node Subnetのどれを使うか |
| Pod CIDR | VNet、Service CIDR、接続先ネットワークと重複していないか |
| NetworkPolicy | ipBlock、hostNetwork、Namespace/Podラベルを確認したか |
| ACNS | FQDN、L7、Flow Logsなどが必要か |
| 移行方式 | IPAM更新とデータプレーン更新を分けているか |
| 運用影響 | ノード再イメージ化、Pod再配置、メンテナンス時間を確保しているか |
| 復旧計画 | 元に戻すのではなく、旧クラスター退避やBlue/Greenを設計しているか |
Azure CNI Powered by Ciliumは、AKSのネットワーク性能、セキュリティ、可視化を強化できる有力な選択肢です。ただし、本番環境では「Ciliumを有効にする」だけでは不十分です。まず現在のネットワーク方式とNetworkPolicyを棚卸しし、必要なACNS機能を判断し、検証クラスターで通信テストを行ってから展開してください。新規クラスターならIPAM方式の選定、既存クラスターなら移行経路とノード再イメージ化の影響確認が、最初に取るべき行動です。
コメント