Contents
前提条件と環境設定
このセクションでは、Cilium を利用するために必須となる Azure と Kubernetes のバージョン要件、CLI のバージョン、および必要な権限やネットワーク設計について説明します。前提が整っていないと、CNI の有効化時にエラーが発生したり、期待通りに動作しなかったりするため、必ず確認してください。
必要な Kubernetes バージョンとノードプール
- Kubernetes バージョン：公式ドキュメント（2023 年 11 月時点）では 1.28 以上 がサポートされています。
- ノードプールの種類：Linux ノードのみ対応し、Windows ノードは対象外です。
推奨される CLI／PowerShell バージョン
| ツール | 最低推奨バージョン | 確認コマンド |
|---|---|---|
Azure CLI (az) |
2.55.0 以上 | az --version |
| PowerShell Az モジュール | 10.5.0 以上 | Get-InstalledModule -Name Az |
バージョンが古い場合は、az upgrade または Update-Module -Name Az で更新してください。
権限とリージョン
- ロール：対象サブスクリプションに Contributor（または同等）と、ネットワークリソース作成が許可されたロールが必要です。
- リージョン：Cilium は一部のリージョンでプレビュー扱いになるため、利用したいリージョンが対象か Azure Portal の「機能プレビュー」ページで事前に確認しましょう。
ネットワーク設計のポイント
- VNet のアドレス空間は /16 以上（例：10.0.0.0/16）を確保すると、Pod 用 IP プールが十分確保できます。
- サブネットは /24 以上 を推奨し、将来的なスケーリングに備えて余裕を持たせます。
まとめ：Kubernetes 1.28+ の Linux ノードプール、最新 Azure CLI／PowerShell、適切な権限と /16 以上の VNet 設計が整っていれば、次の有効化手順へ安全に進められます。
Azure CNI Powered by Cilium の有効化手順
この章では、Cilium を AKS クラスターのネットワークプラグインとして有効化する 3 つの方法（Portal、CLI、ARM テンプレート）を順に紹介します。各方法には実装例と注意点を記載しているので、運用方針や自動化要件に合わせて選択してください。
Portal から有効化する手順
Portal は UI が直感的なため、初回導入時におすすめです。以下の操作で Cilium を有効化できます。
- AKS クラスターの「ネットワーク」ブレードを開く
- Network plugin が
azureのままであることを確認し、CNI mode に Azure CNI powered by Cilium を選択 - 必要に応じて IP アドレスプール（例：2000 個）を入力し、保存ボタンをクリック
留意点：Portal からの変更は内部で
az aks updateが実行されますが、設定内容のスクリプト化や再現性は低くなるため、後続の自動デプロイでは CLI または ARM テンプレートを併用することを検討してください。
CLI (az aks update) で有効化する手順
CI/CD パイプラインに組み込む場合は Azure CLI が最適です。以下コマンド例は Cilium の有効化と IPAM モードの指定を同時に行います（公式ドキュメント参照）。
|
1 2 3 4 5 6 7 |
az aks update \ --resource-group <ResourceGroup> \ --name <ClusterName> \ --network-plugin azure \ --enable-cilium true \ --cilium-ipam-mode overlay # または vnet-integrated |
--enable-cilium trueが CNI のスイッチです。--cilium-ipam-modeは IP アドレス管理方式を選択します。- overlay：Cilium 独自の仮想ネットワークで IP を割り当て、既存 VNet と分離します。
- vnet-integrated（別名 azure-cni）：Azure の IP プールを直接利用し、オンプレミスハイブリッドでもシームレスに動作します。
ポイント：IPAM モードは後から変更できないため、導入前にネットワーク構成と要件を十分検討してください。
ARM テンプレートでのデプロイ例
大規模環境や複数クラスターの一括管理には Infrastructure as Code が有効です。以下は公式サンプルから抜粋した JSON 断片です（apiVersion は最新版に合わせてください）。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
{ "type": "Microsoft.ContainerService/managedClusters", "apiVersion": "2023-11-01", "name": "[parameters('clusterName')]", "location": "[resourceGroup().location]", "properties": { "networkProfile": { "networkPlugin": "azure", "ciliumEnabled": true, "ciliumIpamMode": "overlay" } // 他の必須プロパティは省略 } } |
テンプレートを保存したら、次のコマンドでデプロイします。
|
1 2 3 4 5 |
az deployment group create \ --resource-group <ResourceGroup> \ --template-file cilium-aks.json \ --parameters clusterName=<ClusterName> |
ベストプラクティス：パラメータファイルを環境ごとに分け、Git リポジトリでバージョン管理すると変更履歴が残り、監査やロールバックが容易になります。
Cilium データプレーンのインストールと主要パラメータ
CNI が有効化されたら次は、実際にデータプレーン（Cilium エージェント）をクラスターへデプロイします。ここでは Helm Chart と マニフェスト直接適用 の 2 パターンを示し、主要な values.yaml 設定項目の意味も解説します。
Helm Chart を使ったインストール手順
Helm はリリース管理が容易で、本番環境に最適です。以下は基本的なフローです。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
# 1. リポジトリ登録と更新 helm repo add cilium https://helm.cilium.io/ helm repo update # 2. カスタム values.yaml を作成（抜粋） cat > cilium-values.yaml <<EOF k8sVersion: "1.28" ipam: mode: "azure-cni" # Azure の IP プールと連携 cni: exclusive: true # 他の CNI と競合しないように排他化 hubble: enabled: true # ネットワーク可視化機能 kubeProxyReplacement: "strict" tls: autoGenerate: true # mTLS 用自己署名証明書を自動生成 EOF # 3. デプロイ実行 helm install cilium cilium/cilium -n kube-system -f cilium-values.yaml |
主なパラメータの解説
| パラメータ | 意味 |
|---|---|
ipam.mode |
azure-cni に設定すると Azure の VNet プールを使用し、Pod が VNet 内部 IP を取得します。 |
cni.exclusive |
true 推奨。Cilium 以外の CNI が同時に動作しないようにします。 |
kubeProxyReplacement |
"strict" にすると kube-proxy が完全に置き換えられ、eBPF の高速転送が有効になります。 |
tls.autoGenerate |
デフォルトで Cilium 内部通信を mTLS で保護します（本番では外部証明書への切替も可）。 |
マニフェスト直接適用の手順
Helm が利用できない環境や最小構成のテスト向けに、公式マニフェストをそのまま kubectl で適用します。
|
1 2 3 |
curl -L https://raw.githubusercontent.com/cilium/cilium/v1.15/install/kubernetes/quick-install.yaml \ | kubectl apply -f - |
- 必要に応じて
--set相当の環境変数をkubectl set envで上書きできます。 - デプロイ後は
kubectl edit configmap cilium-config -n kube-systemにより設定変更が可能です。
推奨：本番環境では Helm による管理がアップグレードやロールバックを簡素化するため、デフォルトとして採用してください。
ネットワークポリシーの実装と検証方法
Cilium の最大の魅力は eBPF を活用した高性能ネットワークポリシー です。ここでは CiliumNetworkPolicy（CNP）の基本構文と、代表的な Ingress / Egress ポリシー例、そして実装後の動作確認手順を示します。
CiliumNetworkPolicy の基礎構造
以下は最もシンプルな「frontend から backend のポート 80 を許可」するポリシーです。endpointSelector が対象 Pod、fromEndpoints が通信元、toPorts が許可ポートを定義します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
apiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: allow-frontend-to-backend spec: endpointSelector: matchLabels: app: backend ingress: - fromEndpoints: - matchLabels: app: frontend toPorts: - ports: - port: "80" protocol: TCP |
Ingress と Egress の実装例
1. Namespace 間での通信許可（frontend → backend）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
apiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: ns-allow-frontend spec: endpointSelector: matchLabels: app: backend ingress: - fromEndpoints: - matchLabels: app.kubernetes.io/name: frontend toPorts: - ports: - port: "8080" protocol: TCP |
2. 外部への Egress を遮断し、内部サービスのみに限定
|
1 2 3 4 5 6 7 8 9 10 11 |
apiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: deny-egress-external spec: endpointSelector: {} # 全 Pod に適用 egress: - toEndpoints: - matchLabels: role: internal-service |
ポリシー適用後の確認コマンド
| 操作 | コマンド例 | 確認ポイント |
|---|---|---|
| Cilium の全体ステータス | cilium status --verbose |
エージェント・eBPF プログラム・IPAM が正常か |
| Cilium ポッドの稼働状況 | kubectl get pods -n kube-system -l k8s-app=cilium |
cilium-agent と cilium-operator が Ready であること |
| 作成したポリシー一覧 | cilium policy get |
CNP 名が表示され、期待通りの数が出ているか |
| パケットフローのリアルタイム可視化 | cilium monitor -t flow |
許可・拒否されたトラフィックが正しく記録されるか |
ベストプラクティス：ポリシーを追加したら必ず
cilium statusとkubectl get pods -n kube-systemでコンポーネントのヘルスチェックを行い、cilium monitorで実際に期待通りのフローが流れていることを確認しましょう。
移行・運用ベストプラクティスと次のアクション
Cilium を本番環境へ導入する際は、既存 Azure CNI からの段階的な移行計画と、長期的に安定した運用を支える設定・監視体制が重要です。以下では、IP アドレスプール整理 → 段階的ロールアウト → ダウンタイム最小化 の流れと、Advanced Container Networking Services (ACNS) による mTLS 設定、さらに アップグレード・モニタリング 方法をまとめます。
1. IP アドレスプールと Pod CIDR の整理
- Azure CNI はノードごとに固定 IP を付与し、Pod 用 CIDR が不要です。
- Cilium の
azure-cniモードでは VNet のプールを再利用するため、VNet の空きアドレス数（最低 /16） と サブネットの残容量 を事前に確認してください。
|
1 2 3 4 5 |
az network vnet show \ --resource-group <RG> \ --name <VNetName> \ --query "addressSpace.addressPrefixes" |
- アドレス不足が予想される場合は、サブネットを拡張するか新しいサブネットを追加し、Cilium の IPAM が参照できるようにします。
2. 段階的ロールアウト手順
- テスト用 Namespace に CiliumNetworkPolicy をデプロイし、期待通りの通信が行えるか検証
kubectl cordon <node>とkubectl drain <node> --ignore-daemonsetsで一部ノードだけを Cilium に切り替え- 問題が無ければ 全クラスターへ有効化（CLI の
az aks update --enable-cilium true）
この方式により、障害が発生した場合でも影響範囲を限定でき、迅速なロールバックが可能です。
3. ダウンタイム最小化策
- Pod 再スケジューリングは
kubectl rollout restart deployment/<name>を利用し、一括リスタートで安全に行います。 - Service の外部 IP は変更されないため、クライアント側の設定修正は不要です。
4. ACNS による mTLS 設定
ACNS（Advanced Container Networking Services）を併用すると、Cilium が処理する全トラフィックが相互 TLS（mTLS）で暗号化されます。以下は公式ハウツーに沿った構成例です。
- CRD のインストール
|
1 2 |
kubectl apply -f https://raw.githubusercontent.com/Azure/acns/main/crds/mtls.yaml |
- Cilium の values.yaml に ACNS 設定を追記
|
1 2 3 4 5 6 7 |
acns: enabled: true mtls: mode: strict # 本番は strict、テスト時は permissive が安全 tls: autoGenerate: false # 外部証明書を利用する場合は false に設定 |
- 証明書シークレットの作成（Azure Key Vault から取得した PEM ファイル）
|
1 2 3 4 |
kubectl create secret generic acns-mtls-cert \ --from-file=cert.pem=./tls.crt \ --from-file=key.pem=./tls.key -n kube-system |
- Helm Upgradeで設定を反映
|
1 2 |
helm upgrade cilium cilium/cilium -n kube-system -f cilium-values.yaml |
ポイント：
mode: strictにすると、ポリシー未許可の通信はすべて TLS エラーになります。まずはpermissiveで動作確認し、問題がなければ本番に切り替えましょう。
5. アップグレード・ログ収集・モニタリング
| 項目 | 推奨手法 | 補足 |
|---|---|---|
| Cilium のバージョン管理 | helm upgrade cilium cilium/cilium --version <x.y.z> |
リリースノートで Breaking Change を必ず確認 |
| ログ収集 | Azure Monitor コンテナインサイト + Log Analytics に Cilium ログを転送 | kubectl logs -n kube-system cilium-operator-* で即時取得可 |
| アラート設定 | 「Cilium Pod が CrashLoopBackOff」や「IPAM エラー」を Azure Monitor アラートに追加 | テンプレートは公式ドキュメント参照 |
| トラブルシューティング | cilium status, cilium monitor -t flow, kubectl describe cnp <name> を組み合わせる |
カーネルバージョン不整合が原因の eBPF ロード失敗に注意 |
ベストプラクティス：アップグレード前に AKS のバックアップ（
az aks backup create）を取得し、Helm の--history-maxでリリース履歴を保存しておくとロールバックが迅速です。
用語集（初心者向け）
| 用語 | 説明 |
|---|---|
| CNI | Container Network Interface の略。Kubernetes が Pod にネットワーク機能を付与するプラグイン体系です。 |
| eBPF | Linux カーネル内で安全に実行できるバイトコード。Cilium はこれを使って高速パケット処理とポリシー適用を行います。 |
| Helm | Kubernetes 用のパッケージマネージャ。Chart と呼ばれるテンプレート集合でアプリを簡単にデプロイ・管理できます。 |
| ARM テンプレート | Azure Resource Manager が理解できる JSON/YAML 形式のインフラ定義ファイルです。 |
| IPAM | IP Address Management の略。Cilium の azure-cni モードでは Azure VNet のアドレスプールを利用します。 |
| ACNS | Advanced Container Networking Services の頭文字。Azure が提供するネットワークセキュリティ機能で、mTLS などを実装できます。 |
| CiliumNetworkPolicy (CNP) | Cilium 独自の NetworkPolicy リソース。標準 Kubernetes の NetworkPolicy より高度な表現が可能です。 |
まとめ
- 前提条件（Kubernetes 1.28+、Linux ノード、最新 CLI/PowerShell、適切な権限と VNet 設計）を満たすことが成功の鍵
- Portal・CLI・ARM テンプレートのいずれかで Azure CNI Powered by Cilium を有効化し、その後 Helm でデータプレーンをインストールするのが推奨フロー
- eBPF による高性能ネットワークポリシーは
CiliumNetworkPolicyで実装し、cilium status・cilium monitorで動作確認を徹底 - 移行時は IP プール整理と段階的ロールアウトを行い、ACNS による mTLS で通信の機密性も確保
- アップグレードや障害対応は Helm と Azure Monitor を組み合わせ、バックアップ・リリース履歴で安全に実施
以上の手順とベストプラクティスに沿って構築すれば、Azure 上で高性能かつセキュアな Cilium ネットワークを安定して運用できるようになります。ぜひ本稿を参考に、実際の環境へ適用してみてください。