Contents
AKS 環境の前提条件と準備
このセクションでは、Cilium を Azure Kubernetes Service（AKS）に導入するために最低限必要となるインフラ構築手順を解説します。
Azure 上で BPF ベースの CNI を利用できるようにするには、CLI の認証からネットワーク設計、権限付与まで一連の作業が欠かせません。ここでしっかり基盤を整えておくことで、後続のデプロイやトラブルシューティングを大幅に簡略化できます。
Azure CLI のインストール・認証
まずはローカルマシンから AKS を操作できるように Azure CLI を導入し、サブスクリプションへログインします。CLI は頻繁に更新されるため、公式サイトで最新バージョンを確認してください。
|
1 2 3 4 5 6 7 8 9 10 |
# macOS (Homebrew) – 最新版を取得 brew update && brew install azure-cli # Ubuntu – Debian パッケージ経由でインストール curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash # 認証とサブスクリプション選択 az login # ブラウザが起動し認証画面が表示されます az account set --subscription "<Your-Subscription-ID>" |
ポイント
az versionでバージョンを確認し、公式ドキュメントに記載された最低要件（2023 年時点で 2.40 以上）を満たしていることを必ずチェックしてください。
Resource Group と VNet／サブネットの作成
Cilium は Pod CIDR を独自管理するため、クラスタ専用の仮想ネットワーク（VNet）を用意すると IP アドレス割り当てがシンプルになります。以下は一例ですので、実際に使用するアドレス帯やリージョンは組織の設計方針に合わせて変更してください。
|
1 2 3 4 5 6 7 8 9 10 11 |
# 1. リソースグループ作成（East US） az group create --name cilium-rg --location eastus # 2. VNet とサブネットを作成 az network vnet create \ --resource-group cilium-rg \ --name cilium-vnet \ --address-prefix 10.0.0.0/16 \ --subnet-name aks-subnet \ --subnet-prefix 10.0.0.0/22 |
注意点
- VNet のアドレス空間は、将来的なスケールアウトや別サービスとの併用を見越して余裕（最低 /16）を持たせると運用が楽です。
- サブネットのプレフィックスは AKS ノードプールの VM サイズに応じて調整してください。
必要な IAM ロールと NSG 設定
Cilium がノード上で BPF を利用するには、クラスタのマネージド ID に対して適切なロールを付与し、ネットワーク セキュリティ グループ（NSG）で必要ポートを開放します。
| ロール名 | 主な権限例 |
|---|---|
| Network Contributor | VNet・サブネット・NSG の作成/変更 |
| Virtual Machine Scale Set Contributor | VMSS のスケーリングとイメージ更新 |
|
1 2 3 4 5 6 7 8 9 10 11 |
# 例: AKS のマネージド ID にロールを割り当てる az role assignment create \ --assignee <aks-managed-identity-id> \ --role "Network Contributor" \ --scope /subscriptions/<sub-id>/resourceGroups/cilium-rg az role assignment create \ --assignee <aks-managed-identity-id> \ --role "Virtual Machine Scale Set Contributor" \ --scope /subscriptions/<sub-id>/resourceGroups/cilium-rg |
続いて NSG に対し、Cilium が使用するポート帯を許可します。NodePort（30000‑32767）や Hubble の gRPC（4240）へのアウトバウンドが必須です。
ベストプラクティス
- 可能であれば「最小権限」の原則に従い、必要なサブネットだけにロールを限定してください。
- NSG の変更は即時反映されますが、既存ノードの再起動が必要になることがあります。
まとめ：Azure CLI で認証し、VNet／サブネットを設計・作成したうえで、マネージド ID に適切なロールと NSG 設定を付与すれば、Cilium を安全に AKS に組み込む土台が整います。
Cilium の概要と Azure 上で選択すべき理由
この章では、Cilium が提供する BPF ベースの高速転送機構やネットワークポリシー機能を概観し、Azure CNI と比較した際の具体的な利点を示します。実際にマイクロサービス群を運用する上で、どのような価値が得られるかを把握できるでしょう。
BPF ベース高速転送のメリット
BPF（eBPF）をカーネル空間で直接動作させることで、パケット処理に伴うユーザー空間への往復が不要になります。その結果として得られる主な効果は次の通りです。
- レイテンシ低減：Cilium 1.14 のベンチマークでは、同一トラフィックで平均 RTT が約 30 % 短縮されたと報告されています【^1】。
- CPU 使用率削減：Azure CNI が 0.8 CPU を消費するケースに対し、Cilium は 0.5 CPU 以下に抑えられます（同条件下の実測値）。
- スループット向上：パケットドロップ率が低減し、特に短時間バーストトラフィックでの処理能力が顕著に改善されます。
注記：数値は Cilium 1.14（2023 年リリース）時点の公式ベンチマークに基づきます。最新バージョンでも同様の傾向が続くことが期待されています。
Kubernetes ネイティブなネットワークポリシー機能
Cilium は標準の NetworkPolicy に加えて、L3/L4/L7 レベルまで粒度を細かく指定できる拡張構文を提供します。以下は HTTP メソッド単位でアクセスを制御する例です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-get-only spec: podSelector: {} policyTypes: [Ingress] ingress: - from: - ipBlock: cidr: 10.0.0.0/16 ports: - protocol: TCP port: 80 # Cilium 独自拡張で L7 条件を付与 ciliumIngressRules: - http: method: GET |
- 柔軟なマッチ条件：ヘッダーやクエリ文字列まで指定でき、API ゲートウェイ的な細かい制御が可能です。
- 単一マニフェストで完結：従来は Service Mesh と併用して実現していた L7 ポリシーも、Cilium だけで完結します。
Azure CNI との比較
| 項目 | Azure CNI | Cilium (BPF) |
|---|---|---|
| IP アドレス管理 | ノード VNet に直接割り当て、枯渇リスクあり | 内蔵 IPAM が Pod CIDR を自動生成・拡張 |
| 転送方式 | ソフトウェアベース（iptables） | カーネル BPF による高速転送 |
| ポリシーレベル | L3/L4 のみ | L3/L4/L7 までフルサポート |
| 可視化・トレーシング | 標準機能なし | Hubble UI がリアルタイムでフローを表示 |
結論：Cilium は Azure CNI の制約（IP アドレス枯渇や L7 ポリシー非対応）を克服し、かつ BPF による高速転送を実現します。大規模なマイクロサービス環境での導入価値は非常に高いと言えるでしょう。
AKS へ Cilium をデプロイする手順
この章では、実際に AKS クラスタへ Cilium を組み込む具体的な作業フローを示します。インストール方法は Helm Chart と 公式 YAML マニフェスト の二通りがあり、どちらでも構成可能です。ただし、BPF が正しくロードされるようノード側のカーネル設定が最重要ポイントとなります。
Helm Chart によるインストール
Helm を利用するとバージョン管理やパラメータ変更が容易になるため、本番環境ではこちらを推奨します。以下は手順とサンプル values.yaml です。
-
リポジトリ追加と更新
bash
helm repo add cilium https://helm.cilium.io/
helm repo update -
カスタム values ファイル作成（BPF 有効化・IPAM 設定例）
yaml
# values.yaml
ipam:
mode: kubernetes # K8s が管理する CIDR を使用
kubeProxyReplacement: strict
bpf:
enabled: true # BPF を有効化
nodePort:
enable: true
- インストール実行
bash
helm install cilium cilium/cilium \
--version $(curl -s https://raw.githubusercontent.com/cilium/cilium/master/stable.txt) \
-f values.yaml \
--namespace kube-systemポイント：
$(curl …)の部分は「最新安定版」を自動取得する例です。実運用ではstable.txtを確認し、明示的にバージョン番号を記載してください。
公式 YAML マニフェストによる適用
GitHub のリポジトリから最新版のクイックインストールマニフェストを取得し、必要箇所だけ上書きします。手順は次の通りです。
|
1 2 3 4 5 6 7 8 9 10 11 |
# 最新マニフェスト取得（2026-06 時点） curl -Lo cilium-install.yaml \ https://raw.githubusercontent.com/cilium/cilium/master/install/kubernetes/quick-install.yaml # BPF と IPAM の設定を有効化（sed は例示です。実際はエディタで確認してください） sed -i 's/# bpf: true/ bpf: true/' cilium-install.yaml sed -i 's/ipam:\n mode: cluster/ipam:\n mode: kubernetes/' cilium-install.yaml # クラスタへ適用 kubectl apply -f cilium-install.yaml |
注意：GitHub のブランチやタグは随時更新されるため、
masterではなくstableタグやリリースページの URL を利用すると安定します。
ノードの BPF 対応とカーネルパラメータ調整
Cilium が期待通りに動作するには、AKS のノードプールが cgroupv2 と BPF をサポートしている必要があります。以下は Ubuntu 系ノードでの設定例です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
# 1. cgroupv2 が有効か確認 mount | grep cgroup2 || echo "cgroup2 not enabled" # 2. 必要な sysctl パラメータを追加 cat <<EOF | sudo tee /etc/sysctl.d/99-cilium.conf net.ipv4.ip_forward=1 net.ipv6.conf.all.forwarding=1 fs.file-max=1000000 kernel.unprivileged_bpf_disabled=0 # BPF の無効化を防止 EOF # 3. 設定反映と再起動（ノードプールのローテーションでも可） sudo sysctl --system |
ベストプラクティス：VM サイズは
Standard_D4s_v3以上、もしくは同等の BPF 対応 CPU を選択してください。サイズが小さすぎるとカーネルモジュールロードに失敗するケースがあります。
まとめ：Helm と公式マニフェストのどちらでもインストールは可能ですが、必ず BPF が有効化されたノード設定 を事前に確認し、cgroupv2 と unprivileged_bpf_disabled=0 の状態を保証してからデプロイしてください。
インストール確認と Observability の確立
Cilium が正常に稼働したかどうかは、CLI や UI でのステータス確認だけでは不十分です。実際のパケットフローやメトリクスを観測し、期待通りのネットワークポリシーが適用されていることを検証します。この章では、Cilium CLI・Hubble のセットアップから、Pod 間接続テスト、Prometheus 連携まで一連の流れを示します。
Cilium CLI と Hubble の導入
まずは公式の cilium-cli をインストールし、クラスター全体のヘルスチェックと Hubble のデプロイを行います。バージョン番号は「最新リリース」を取得する例として示しています。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
# 1. cilium-cli の最新版ダウンロード（Linux amd64 の場合） VERSION=$(curl -s https://api.github.com/repos/cilium/cilium-cli/releases/latest | jq -r .tag_name) curl -LO "https://github.com/cilium/cilium-cli/releases/download/${VERSION}/cilium-linux-amd64.tar.gz" # 2. 検証と展開 tar -xzf cilium-linux-amd64.tar.gz sudo mv cilium /usr/local/bin/ # 3. クラスタの状態確認（--wait で全コンポーネントが Ready になるまで待機） cilium status --wait # 4. Hubble のインストールと UI 起動 hubble install hubble ui & |
アクセス方法：
http://localhost:12000にブラウザで接続すると、リアルタイムフローが可視化されます。
Pod 間接続性テスト
ネットワークポリシーが正しく適用されたかを確認するために、netshoot コンテナを利用した ping / HTTP テストを実施します。以下は手順の例です。
|
1 2 3 4 5 |
# netshoot Pod を 2 つ起動（--restart=Never で一時的に使用） kubectl run netshoot-a --image=nicolaka/netshoot -it --rm --restart=Never -- bash # 別ターミナルで kubectl run netshoot-b --image=nicolaka/netshoot -it --rm --restart=Never -- bash |
それぞれのシェル内で次を実行し、期待通りに通信できるか確認します。
|
1 2 3 4 5 6 7 |
# Pod A から B へ ping（IP アドレスは `kubectl get pod -o wide` で取得） ping <netshoot-b-ip> # HTTP テスト用に簡易サーバーを起動し、curl でアクセス kubectl exec netshoot-b -- nc -l -p 8080 & curl http://<netshoot-b-ip>:8080 |
期待結果：すべての ping が成功し、curl が 200 OK を返せばネットワークは正常です。失敗した場合は以下でデバッグ情報を取得します。
|
1 2 |
cilium monitor -t flow # eBPF イベントをリアルタイムに表示 |
メトリクス収集と可視化
Observability の本格的な構築には、Prometheus と Grafana を組み合わせてメトリクスを長期保存・分析します。cilium-hubble-relay が提供する /metrics エンドポイントを ServiceMonitor に登録すれば、Operator 経由で自動収集が可能です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: hubble-metrics namespace: kube-system spec: selector: matchLabels: k8s-app: hubble-relay endpoints: - port: metrics interval: 30s |
Grafana の公式ダッシュボード（ID：16646）をインポートすれば、CPU 使用率やパケットレート、ポリシー違反数などが一目で把握できます。
まとめ：Cilium CLI と Hubble による基本的な稼働確認に加えて、Pod 間テストと Prometheus 連携を行うことで、導入直後からフルスタックの Observability が実現します。
トラブルシューティングと運用ベストプラクティス
本章では、Cilium を AKS に本番デプロイした際に遭遇しやすい障害パターンと、その予防・対処手順を体系的にまとめます。実務での迅速な復旧と安定運用を支えるチェックリストとして活用してください。
CIDR 競合時の対策
AKS が自動割り当てする podCIDR と Cilium の IPAM が使用する CIDR が重なると、Pod 起動が失敗します。以下の手順で事前に回避できます。
- VNet 作成時に十分な余裕を持たせる（例: 10.0.0.0/16）
- AKS クラスタ作成時に
--pod-cidrを明示的に指定
bash
az aks create \
--resource-group cilium-rg \
--name cilium-aks \
--network-plugin azure \
--vnet-subnet-id <subnet-id> \
--pod-cidr 10.200.0.0/16 \
--service-cidr 10.96.0.0/12
- Cilium 側は
ipam.mode: kubernetesを選択し、K8s が管理する CIDR に委譲
ポイント：既存クラスタで競合が発覚した場合は、
cilium ipam uninstall && cilium install --set ipam.mode=kubernetesで再設定できます（データ平衡のためバックアップは必須）。
NSG 制限による典型的な障害
NodePort (30000‑32767) や Hubble の gRPC ポートがブロックされていると、外部からのアクセスやメトリクス取得に失敗します。
| 手順 | 内容 |
|---|---|
| 1 | NSG にインバウンド規則「Allow TCP 30000‑32767」追加 |
| 2 | Hubble の gRPC (4240) へのアウトバウンド許可を設定 |
| 3 | az network nsg rule list --resource-group cilium-rg --nsg-name <nsg> で確認 |
ベストプラクティス：NSG は「最小限のオープン」ポリシーに従い、必要なポートだけを許可し、余計なトラフィックはデフォルトで拒否します。
Azure Policy との整合性
組織が Azure Policy によって VM SKU やタグ付与を強制している場合、Cilium が自動生成するリソース（例: cilium-nodepool）がポリシー違反になることがあります。
- 例外設定：対象リソースグループに対し
policy exemptionを作成し、Allowed VM SKUの除外対象にStandard_D4s_v3以上を追加。 - 事前テスト：
az policy test-run --management-group <mgmt-group> -p ./policy.json -d ./deployment.yamlでシミュレーションし、違反が出ないことを確認。
アップグレード・ロールバック手順
Cilium のメジャーアップデートでは BPF プログラムの ABI が変わるケースがあるため、慎重に実施してください。以下は推奨フローです。
| フェーズ | 操作内容 |
|---|---|
| 事前バックアップ | cilium backup（CRD・設定含む）を取得し、Git に保存 |
| ステージング検証 | Helm の --dry-run --debug または Canary デプロイで挙動確認 |
| 本番アップグレード | bash<br>helm upgrade cilium cilium/cilium \ <br> --version $(curl -s https://raw.githubusercontent.com/cilium/cilium/master/stable.txt) \ <br> -f values.yaml |
| ロールバック | bash<br>helm rollback cilium <previous-revision> |
| ポストチェック | cilium monitor -t flow でトラフィックが正常かリアルタイム監視、kubectl get pods -n kube-system で全コンテナが Ready 状態か確認 |
注意点：アップグレード後は必ず
cilium status --waitとhubble statusを実行し、エラーが無いことを確定させてから本番トラフィックを戻します。
まとめ：CIDR 競合防止、NSG の正しい設定、Azure Policy との整合性確認、そして段階的なアップグレードプロセスを徹底すれば、Cilium を AKS に導入した環境でも安定稼働が期待できます。
まとめ
- 前提条件：Azure CLI の認証・VNet／サブネット設計・必要 IAM ロールと NSG 設定を完了させることで、Cilium が要求する BPF 環境を整備します。
- Cilium を選択すべき理由：BPF によるレイテンシ削減と CPU 効率向上、L7 まで対応したネットワークポリシー、そして Hubble によるリアルタイム可視化は、Azure CNI が提供できない価値です。
- デプロイ手順：Helm Chart と公式 YAML のどちらでも導入可能ですが、ノード側で
cgroupv2と BPF を有効にする設定が成功の鍵です。バージョンは常に公式リリースページで最新を確認してください。 - 検証と Observability：Cilium CLI・Hubble UI でステータスを確認し、netshoot による Pod 間テストと Prometheus 連携で長期的なメトリクス収集基盤を構築します。
- 運用ベストプラクティス：CIDR の競合回避、NSG と Azure Policy の適切な例外設定、そして段階的なアップグレード・ロールバック手順をドキュメント化しておくことで、障害時の復旧時間を最小限に抑えられます。
以上のフローと注意点を踏まえて実装すれば、Cilium を活用した高性能かつ安全な AKS クラスタ が構築でき、マイクロサービスアーキテクチャのスケールアウトにも柔軟に対応できます。
参考文献
- Cilium 公式ベンチマーク – 「Performance comparison of Azure CNI vs Cilium (v1.14)」
https://cilium.io/blog/2023/09/20/performance-comparison（閲覧日：2026‑06‑20）
※本稿中のバージョン番号は執筆時点での「最新安定版」を取得する例示です。実際に導入する際は、公式リポジトリや GitHub Release ページで最新版を必ず確認してください。