Contents
前提条件と環境設定
このセクションでは、Cilium を利用できる AKS のバージョン要件、ネットワークプラグインの選択肢、および Azure CLI/ロール設定についてまとめます。前提が整っていないとデプロイ時にエラーが頻発するため、必ず確認してください。
対応 AKS バージョンとネットワークプラグインの選択
Cilium は AKS 1.27 以降 のマネージドクラスターで公式サポートされています。推奨される CNI は Azure CNI‑Overlay(標準 Azure CNI に対し、Pod CIDR が VNet と自動連携する)です。
- AKS バージョン:
1.27.x以上 - ネットワークプラグイン:
azure(Azure CNI)またはoverlay(Azure CNI‑Overlay)※後者を推奨
公式ドキュメントでサポート対象バージョンが確認できます → https://learn.microsoft.com/ja-jp/azure/aks/network-policy-best-practices#cilium-support。
Azure CLI と必要なロール
| 項目 | 推奨設定 |
|---|---|
| Azure CLI バージョン | 2.55.0 以上(az versionで確認) |
| クラスタ作成時オプション | --network-plugin overlay(CNI‑Overlay 使用時) |
| 必要ロール | - Owner または Contributor(リソースグループ) - Azure Kubernetes Service RBAC Viewer/Writer(クラスター) |
※注意:
--enable-ciliumフラグは 2026 年現在存在しません。Cilium の有効化は、クラスター作成後に Helm でデプロイする手順で行います。
Cilium のインストールと初期構成
この章では、Helm を用いた標準的なインストール手順と、Marketplace 利用時の留意点、RBAC/CRD の確認方法を解説します。Helm チャートは頻繁に更新されるため、実装前に必ず最新の values リファレンスを取得してください(例:helm show values cilium/cilium)。
Helm でのデプロイ手順
以下では、Cilium の公式 Helm リポジトリから最新版を取得し、Azure CNI‑Overlay に合わせた設定でインストールする流れを示します。
-
Helm リポジトリの追加と更新
bash
helm repo add cilium https://helm.cilium.io/
helm repo update -
Namespace と ServiceAccount の作成(RBAC 用)
yaml
apiVersion: v1
kind: Namespace
metadata:
name: kube-system
apiVersion: v1
kind: ServiceAccount
metadata:
name: cilium
namespace: kube-system
kubectl apply -f で適用します。
上記マニフェストは
- Cilium 本体のインストール
bash
helm install cilium cilium/cilium \
--namespace kube-system \
--set serviceAccount.name=cilium \
--set enableK8sNetworkPolicy=true \ # バージョンによってはk8sNetworkPolicyに変更になることがあります
--set l7Proxy=true \ # L7 ポリシー有効化。Chart のバージョンで名称が変わる可能性あり
--set ipam.mode=cluster-pool \
--set tunnel=vxlan \
--wait enableK8sNetworkPolicyとl7Proxyは L7 ポリシー を利用する上で必須です。-
変数名は Helm chart のバージョン差分に注意し、公式リリースノートを参照してください(例:
cilium/k8sNetworkPolicy)。 -
インストール完了の確認
bash
kubectl -n kube-system get pods -l k8s-app=cilium
cilium status --wait
すべてRunning、かつcilium statusがReadyを示せば成功です。
Marketplace 利用時の留意点
Marketplace の「Cilium for AKS」テンプレートは UI 操作で導入できますが、以下を手動で確認・設定する必要があります。
- ネットワークプラグイン:必ず
Overlay(Azure CNI‑Overlay)を選択 - RBAC:
cilium-agentに対してClusterRoleとClusterRoleBindingを付与 - バージョン指定:公式リポジトリの最新安定版(例:
v1.15.x系)と一致させる
導入後は必ず cilium status で稼働状態をチェックしてください。
RBAC と CRD の確認方法
Helm が自動生成する CRD はクラスター全体で有効になる必要があります。インストール直後に次のコマンドで登録状況を確認します。
|
1 2 |
kubectl get crd | grep cilium |
表示例:
|
1 2 3 4 |
ciliumnetworkpolicies.cilium.io ciliumclusterwidenetworkpolicies.cilium.io ... |
CRD が欠落している場合は、helm install 時に --set installCRDs=true を付与し再実行してください。
L7 ネットワークポリシーの概念と実装例
Cilium の最大の特徴は eBPF による L7 可視化・制御 です。本節では CiliumNetworkPolicy の構文を解説し、代表的な YAML サンプルを提示します。
CiliumNetworkPolicy の基本構文
| フィールド | 説明 |
|---|---|
apiVersion |
cilium.io/v2(Cilium 1.12 以降) |
kind |
CiliumNetworkPolicy |
metadata.name |
ポリシーの一意な名前 |
spec.endpointSelector |
対象 Pod のラベルセレクタ |
spec.ingress / spec.egress |
通信方向ごとのルール定義 |
spec.http |
L7 フィールド。method, path, host, headers で絞り込み可能 |
httpMatch 配列は OR 条件、配下の headers は AND 条件として評価されます。
サンプル①:GET メソッド+特定ホスト名だけを許可
以下のポリシーは、ラベル app=frontend の Pod が GET リクエストかつ host が example.com の場合にのみ 80/TCP を通過させます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
apiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: allow-get-example-com spec: endpointSelector: matchLabels: app: frontend ingress: - fromEndpoints: - matchLabels: role: client # 任意の送信元ラベル toPorts: - ports: - port: "80" protocol: TCP rules: http: - method: GET host: "example.com" |
ポイント:
methodとhostの組み合わせにマッチしないリクエストはすべて遮断されます。
サンプル②:正規表現で特定パスをブロックし 403 を返す
この例では、/admin/.* に対する全トラフィックを拒否し、HTTP 403 ステータスコードで応答させます。TLS (443) のみ対象です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
apiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: block-admin-path spec: endpointSelector: matchLabels: app: backend ingress: - fromEndpoints: - {} # 任意の送信元 toPorts: - ports: - port: "443" protocol: TCP rules: http: - path: "/admin/.*" deny: responseCode: 403 |
ポイント:
pathは PCRE 形式の正規表現で評価され、マッチしたリクエストは即座にdenyに転じます。
ポリシー適用後の検証と可観測性
ポリシーが期待通りに機能しているかを確認する手段として、Pod から直接リクエストを送る方法 と Cilium の Observability ツール(Hubble) を組み合わせます。
kubectl exec + curl での動作確認
-
テスト用 Pod(curl が入ったイメージ)を起動
bash
kubectl run test-client \
--image=curlimages/curl \
--restart=Never \
-it --rm -- /bin/sh -
許可されたリクエストの確認(GET + example.com)
bash
curl -I http://example.com/
# 200 OK が返ればポリシーは正しく許可しています -
ブロック対象リクエストの確認(admin パスへのアクセス)
bash
curl -I https://backend.example.internal/admin/settings
# 403 Forbidden が期待されます
テスト結果がポリシー定義と一致しない場合は、endpointSelector のラベルや fromEndpoints 設定を再確認してください。
Hubble UI と CLI の活用方法
| ツール | 主な用途 |
|---|---|
| Hubble UI(Web) | フローの可視化、ポリシー適用状況のリアルタイム表示 |
| hubble observe(CLI) | 特定 Pod → FQDN・プロトコルで絞り込んだフローログ取得 |
Hubble UI のインストール手順
|
1 2 3 4 5 6 7 8 |
# Hubble CLI がまだ無い場合はインストール curl -L --output /usr/local/bin/hubble https://github.com/cilium/hubble/releases/download/v0.12.0/hubble-linux-amd64.tar.gz chmod +x /usr/local/bin/hubble # UI をデプロイしポートフォワード hubble install --ui kubectl -n kube-system port-forward svc/hubble-ui 12000:80 & |
ブラウザで http://localhost:12000 にアクセスすると、Flows タブに allow-get-example-com や block-admin-path の適用結果が表示されます。
CLI でフローを絞り込む例
|
1 2 3 4 5 6 |
hubble observe \ --from-pod test-client \ --to-fqdn example.com \ --protocol http \ --since 5m |
このコマンドは過去 5 分間の test-client から example.com への HTTP フローを出力し、許可/拒否のステータスが確認できます。
NPM(Network Policy Manager)から Cilium への移行ガイド
Azure の従来ネットワークポリシー管理ツール NPM を使用している環境でも、段階的に Cilium へ切り替えることが可能です。以下では、安全かつ再現性の高い移行手順を示します。
移行フロー概要
| ステップ | 作業内容 | 推奨方法 |
|---|---|---|
| 1. 現行ポリシーの取得 | NPM の設定情報をエクスポート | Azure Portal から「Network policy」→「Export as JSON」または az network nsg list 等で手動抽出 |
| 2. ポリシー変換 | JSON → CiliumNetworkPolicy YAML にマッピング | 社内スクリプト (npm-to-cilium.py) または手作業で spec.ingress/egress を再構築 |
| 3. テストクラスターへ適用 | 変換した YAML をテスト環境にデプロイ | kubectl apply -f <policy>.yaml --dry-run=client で検証後、本番へ適用 |
| 4. 本番クラスタへのロールアウト | 段階的に Cilium ポリシーを有効化 | Hubble でフローをモニタリングし、問題がなければ enforcement: true に切り替える |
重要:
az aks network-policy exportは現行 Azure CLI には実装されていません。代わりに上記の手順でポリシー情報を取得してください。
ベストプラクティスとロールアウト戦略
- 最小特権の徹底
CiliumNetworkPolicyのendpointSelectorとfromEndpointsを細かく絞り、ワイルドカードは極力使用しない。- 段階的導入(Canary)
- 新規ポリシーはまず dry‑run で適用し、
hubble observe --enforcement=disabledで影響範囲を確認。問題がなければenforcement: trueに変更。 - ロギングとアラート
- Cilium の
cilium-monitorと Azure Monitor を連携し、policy deniedイベントを「警告」レベルで通知するよう設定。
よくあるエラーと対処法
| エラー | 原因例 | 対策 |
|---|---|---|
| cilium-agent が CrashLoopBackOff | ノード OS が eBPF 未対応(古いカーネル) | Ubuntu 22.04+、または AKS の --node-osdisk-type Ephemeral を使用した最新ノードプールに更新 |
| Pod CIDR 不整合 | クラスター作成時の --pod-cidr と Cilium の clusterPoolIPv4CIDR が不一致 |
cilium-config の ipam.clusterPoolIPv4CIDR を VNet サブネットと合わせ、必要に応じてクラスター再作成 |
| ポリシーが適用されない | endpointSelector のラベルミスマッチ |
kubectl get pod -L <label> で実際のラベルを確認し、YAML 側を修正 |
| Hubble がフローを取得できない | Cilium の monitor-aggregation が無効化されている |
Helm デプロイ時に --set monitorAggregation=medium を追加 |
まとめ
- 前提条件:AKS 1.27+、Azure CNI‑Overlay、Azure CLI 2.55.0 以上を必ず満たす。
- インストール手順:Helm チャートで Cilium をデプロイし、
enableK8sNetworkPolicyとl7Proxy(バージョン依存)を有効化。Marketplace は UI が便利だが RBAC の二重確認が必要。 - L7 ポリシー:
CiliumNetworkPolicyのhttpフィールドでメソッド・パス・ホスト単位の細かい制御が可能。サンプル YAML をベースに自環境へ合わせて調整。 - 検証方法:
kubectl exec + curlに加えて、Hubble UI/CLI でリアルタイムフローを観測し、期待通りの Allow / Deny が出ているか確認。 - NPM → Cilium 移行:Export(Portal)→ Convert(スクリプト/手作業)→ Apply(dry‑run → enforcement)という段階的アプローチが安全。
az aks network-policy exportは非対応なので、代替取得方法を必ず使用。 - トラブルシューティング:eBPF 非対応ノードや CIDR 不整合は最も頻出する障害。公式ドキュメントと
cilium status --verboseで情報収集し、適切に対処。
以上の手順・ベストプラクティスを踏むことで、AKS 上で Cilium の L7 ネットワークポリシーを本番環境レベルで安全かつ可観測的に運用できるようになります。ぜひ実際のクラスターに適用し、Cilium が提供する高度なトラフィック制御と observability を体感してください。