Cilium 入門・インストールと高度なネットワークポリシー完全ガイド

Cilium の概要と Kubernetes における役割

Cilium は eBPF（extended Berkeley Packet Filter）を活用したデータプレーンを提供し、Kubernetes クラスタのネットワーク制御とセキュリティポリシーを統合的に管理できるソフトウェアです。従来の CNI プラグインが L3/L4 の転送だけを担うのに対し、Cilium はカーネル内部でパケット処理を行うことで高性能かつ柔軟な制御を実現します。本セクションでは、その主な機能と Kubernetes への組み込み方を概観します。

BPF‑ベースの高速転送

eBPF プログラムは Linux カーネル空間で直接実行されるため、パケットがユーザー空間に出入りするオーバーヘッドが大幅に削減されます。具体的には iptables と比較してレイテンシが 30〜50% 程度改善され、スループットも向上します。

Kubernetes CNI としての位置付け

Cilium の DaemonSet が各ノード上で起動し、Pod に対して仮想ネットワークインターフェース（cilium_netdev）を割り当てます。これにより、Kubernetes API Server から取得した Pod ラベル情報がそのまま Security Identity として利用でき、IP アドレスの変動に左右されないポリシー適用が可能です。

主な機能

要点：Cilium が提供する BPF データプレーンと Identity により、Kubernetes 環境で高速かつ粒度の細かいネットワーク制御が実現できます。

インストール手順とバージョン確認（2026 年最新版）

本章では Cilium を Kubernetes クラスタに導入する際の前提条件、各インストール方法の概要、およびインストール後のバージョン検証手順を解説します。実運用で必要になるカーネル要件や eBPF の有効化情報も合わせて記載しています。

前提条件とカーネル要件

Cilium が正常に動作するためには、以下の条件が最低限必要です（2026 年時点の公式要件）。

カーネル設定は次のコマンドで確認できます。

リリースバージョンの扱いについて

本稿では執筆時点で最新とされる v1.15.0 を例示していますが、実際に導入する際は公式 GitHub の Releases ページ（ https://github.com/cilium/cilium/releases ）で最新版を確認してください。バージョン番号は 6 ヶ月ごとのマイナーバージョン更新が行われるため、v1.15.x 系がリリースされた後でも v1.16.x がすでに提供されている可能性があります。

Helm によるデプロイ

Helm は Kubernetes のパッケージマネージャとして広く使われており、Cilium も公式チャートが用意されています。以下は Helm を利用した基本的なインストール手順です。

1. リポジトリの追加と更新
   bash
helm repo add cilium https://helm.cilium.io/
helm repo update

2. デフォルト設定でインストール（Kubernetes 1.30+、cgroup v2 が有効な環境を想定）
   bash
helm install cilium cilium/cilium \
--namespace kube-system \
--create-namespace \
--set ipam.mode=kube-ipam \
--set hubble.enabled=true \
--version "$(curl -s https://raw.githubusercontent.com/cilium/cilium/master/stable.txt)"
stable.txt は最新版のタグを自動取得するための簡易スクリプトです。手動でバージョン番号を指定したい場合は --version 1.15.0 のように置き換えてください。

3. クラウドプロバイダ固有設定例

4. AWS ENI：--set eni.enabled=true --set eni.instance-id=$(curl -s http://169.254.169.254/latest/meta-data/instance-id)
5. Azure CNI：--set azure.enabled=true

Helm によるインストールは values.yaml で細かくカスタマイズでき、GitOps ツールと組み合わせて再現性の高いデプロイが可能です。

Operator を使った自動管理

Cilium Operator は CNI の他に IPAM や BGP、ClusterMesh といった高度な機能を CRD（Custom Resource Definition）で宣言的に管理します。Operator による導入手順は次の通りです。

1. CRD と Operator 本体の適用
   bash
kubectl apply -f https://raw.githubusercontent.com/cilium/operator/master/install/k8s.yaml

2. CiliumInstallation カスタムリソースを作成（例：kube-ipam 使用）
   yaml
apiVersion: cilium.io/v2alpha1
kind: CiliumInstallation
metadata:
name: default
namespace: kube-system
spec:
version: "latest" # latest は Operator が自動で最新タグを取得
ipamMode: kube-ipam
hubble:
enabled: true

3. 適用
   bash
kubectl apply -f cilium-installation.yaml

Operator がバックグラウンドで Cilium のデプロイ・アップグレード・ロールバックを監視し、期待通りの状態が保たれない場合は自動で再適用します。

kubeadm ディレクトリへのマニフェスト適用

kubeadm で作成したクラスターでは、/etc/kubernetes/manifests 配下に配置するだけで kubelet が Pod として Cilium を起動します。手順は以下の通りです。

1. 公式マニフェスト取得（バージョンは latest タグを利用）
   bash
curl -L https://github.com/cilium/cilium/releases/download/latest/cilium.yaml \
-o /etc/kubernetes/manifests/cilium.yaml

2. kubelet が自動的にデプロイ
   マニフェストが配置されると、kubelet が即座に cilium Pod を起動し、ノードの CNI 設定を上書きします。

この方式はシンプルですが、設定変更時にはマニフェストファイルを書き換えて kubelet の再起動が必要になる点に注意してください。

バージョン確認方法

導入後に実際に走っている Cilium のバージョンやエージェントの状態を確認する手順です。

• Cilium CLI
  bash
cilium version
# 出力例: cilium-cli v0.15.2, cilium-agent 1.15.0 (2026-03-12)

• Pod のイメージタグ確認
  bash
kubectl get pods -n kube-system -l k8s-app=cilium -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[0].image}{"\n"}{end}'

• ステータスの詳細取得
  bash
cilium status --verbose

バージョン情報は cilium version の出力だけでなく、cilium status に含まれる Cluster や K8s の情報も合わせて確認すると、アップグレード時のトラブルを防げます。

NetworkPolicy の比較：Kubernetes 標準 vs CiliumNetworkPolicy

このセクションでは標準 NetworkPolicy と拡張版 CiliumNetworkPolicy を機能観点で比較し、どちらを選択すべきかの指針を示します。

主な違いと拡張ポイント

以下の表は両者の対応レイヤやマッチング対象をまとめたものです。各項目は実務上頻繁に直面する要件に焦点を当てています。

CiliumNetworkPolicy は「ゼロトラスト」的なデフォルト拒否モデルを前提としており、Identity ベースの粒度が高いためマイクロサービス間の細かい制御に適しています。

選択指針

• シンプルなネットワーク分離（例：名前空間単位で外部アクセスを遮断） → 標準 NetworkPolicy でも十分です。
• アプリケーション層の可視化・制御が必要（例：特定 API エンドポイントだけ許可、Kafka トピックごとのアクセス制限） → CiliumNetworkPolicy が有力です。
• 既存インフラで cgroup v2 が未導入の場合は、標準ポリシーでまずは基礎的な分離を行い、段階的に Cilium へ移行することが推奨されます。

実践サンプル：CiliumNetworkPolicy の作成・適用と検証

本節では実際に CiliumNetworkPolicy を記述し、Ingress／Egress に加えて L7 フィルタを組み込む例を示します。最後にポリシーが正しく機能しているか確認する手順も併せて解説します。

Ingress と Egress の基本例

以下は backend Pod への inbound（8080/TCP）と、database への outbound（5432/TCP）を許可するシンプルなポリシーです。endpointSelector が対象 Pod を特定し、fromEndpoints / toEndpoints が通信元・先のラベルでマッチさせます。

ポイント：IP アドレスではなくラベルでマッチングするため、Pod の再スケジューリングや IP 変更があってもポリシーは自動的に適用され続けます。

L4/L7 フィルタ付きポリシー例

次の例は api-gateway に対して、role=client の Pod が GET /v1/orders/* だけ通過できるよう制限したものです。L4 ポート（80/TCP）に加えて L7 の HTTP メソッドとパスを条件にしています。

ポイント：rules.http 配列に記述できる項目は method, path, host, headers など多岐にわたり、細かい API 単位でのアクセス制御が可能です。

適用後の動作確認手順

1. ポリシー適用
   bash
kubectl apply -f allow-frontend-to-backend.yaml
kubectl apply -f http-get-filter.yaml

2. Cilium エージェントがポリシーを認識したか確認
   bash
cilium policy get allow-frontend-to-backend
cilium policy get http-get-filter

3. ステータスの待機（エージェントが最新状態になるまで）
   bash
cilium status --wait

4. リアルタイムモニタリングでトラフィックを観測
   bash
# L7 レベルまで出力
cilium monitor -t L7

5. Pod から実際にリクエストを送信し、期待通りの結果になるかテスト

Ingress/Egress のベーシックチェック
bash
# frontend → backend (許可)
kubectl exec -n prod -it $(kubectl get pod -l app=frontend -o jsonpath='{.items[0].metadata.name}') \
-- curl -s http://backend:8080/healthz

# frontend → database (未許可のポート例)
kubectl exec -n prod -it $(kubectl get pod -l app=frontend -o jsonpath='{.items[0].metadata.name}') \
-- nc -vz database 3306


L7 フィルタの検証
bash
# GET リクエスト (許可)
kubectl exec -n prod -it $(kubectl get pod -l role=client -o jsonpath='{.items[0].metadata.name}') \
-- curl -s http://api-gateway/v1/orders/123

# POST リクエスト (ブロックされるはず)
kubectl exec -n prod -it $(kubectl get pod -l role=client -o jsonpath='{.items[0].metadata.name}') \
-- curl -X POST -s http://api-gateway/v1/orders/123


期待通りに POST が 403 系のステータスで失敗すれば、L7 フィルタが正しく機能しています。

トラブルシューティングとベストプラクティス

本章ではポリシーが効かないケースや運用上の注意点をまとめ、安定した Cilium 環境を構築するための実践的な手順をご紹介します。

ポリシーが期待通りに適用されない時のチェックリスト

代表的な対処例

• エージェントが停止している場合
  bash
kubectl rollout restart daemonset cilium -n kube-system

• IPAM エラー
  bash
cilium ipam uninstall && cilium ipam install

• BPF がロードされていない（カーネルアップデートまたはブートオプションの修正）
  bash
# カーネルパラメータを確認し、必要なら再起動
grep -i bpf /boot/config-$(uname -r)

運用上のベストプラクティス

1. 名前空間単位で Default‑Deny を設定
   yaml
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: default-deny-all
namespace: prod
spec:
endpointSelector: {}
ingress: [] # すべての Ingress を遮断
egress: [] # すべての Egress を遮断
   ゼロトラストを基本方針とし、許可したい通信だけを個別にポリシーで追加します。

2. ポリシーは機能単位でファイル分割

3. ingress-allow.yaml、egress-db.yaml など目的別に管理し、kustomize や helm の patchesStrategicMerge 機構で統合すると差分が見やすくなります。

4. CI/CD パイプラインでポリシー検証

5. PR 時点で cilium policy verify --from-yaml <policy.yaml> を実行し、シンタックスエラーや未使用ラベルを早期に発見。

6. kind クラスター上で自動テスト（curl, grpcurl）を走らせ、期待通りにブロック／許可されるかを検証します。

7. BPF マップの定期的なメンテナンス

8. 大規模クラスターではマップサイズが増大しパフォーマンス低下の原因になることがあります。以下コマンドでサイズを確認し、必要に応じてリセットしてください。
   bash
cilium bpf map list | grep -E 'policy|lb' # サイズ表示
cilium bpf policy delete --all # 全ポリシーマップのクリア（再適用が必要）

9. 可視化と監視

10. Hubble UI をデプロイし、L7 トラフィックフローやポリシー違反をリアルタイムで確認。

11. Prometheus エクスポートされたメトリクス（cilium_flow_*, cilium_policy_*）を Grafana ダッシュボードに組み込み、異常検知アラートを設定します。

12. アップグレード時の安全策

13. 現行バージョンで cilium status --verbose を取得し、全コンポーネントが Ready 状態か確認。
14. Helm の場合は helm upgrade --install ... --dry-run でマニフェストを事前検証。
15. Operator 利用時は CiliumInstallation の version フィールドだけを書き換えて kubectl apply -f、Operator がロールアウトを自動管理します。

要点：チェックリストで迅速に原因切り分けし、Default‑Deny・ポリシー分割・CI テストというベストプラクティスを組み合わせることで、Cilium の運用リスクを最小化できます。

まとめ

• Cilium は eBPF を核にした高速データプレーンと Identity ベースのポリシーで、Kubernetes におけるネットワーク制御を次世代レベルへ引き上げます。
• インストールは Helm・Operator・kubeadm マニフェストのいずれでも可能ですが、カーネル 5.10 以上・eBPF 有効化・cgroup v2 が必須条件です。最新版は公式リポジトリで随時確認してください。
• 標準 NetworkPolicy と比較すると、Cilium の拡張版は L7 フィルタや DNS/Service 名ベースのマッチングを提供し、ゼロトラスト実装に適しています。
• 実践サンプルでは Ingress/Egress に加えて HTTP GET 限定ポリシーを示し、cilium monitor と curl テストで動作検証する流れを紹介しました。
• トラブルシューティングは「エージェント状態」「IPAM」「BPF マップ」「ラベル一致」の四点に絞ってチェックリスト化し、ベストプラクティスとして Default‑Deny、ポリシー分割、CI/CD テスト、定期的な BPF マップクリア、Hubble 可視化を推奨します。

以上のポイントを踏まえて導入・運用すれば、Cilium が提供する高度なネットワーク機能とセキュリティポリシーを安定して活かせるはずです。