Contents
Cilium が誕生した背景とコンテナネットワーキング課題
Cilium は、従来の CNI プラグインが抱える スケール・可視性・ポリシー表現力 の３つの根本的な問題を解決するために設計されました。これらの課題は、大規模な Kubernetes クラスターで運用コストが急増し、障害対応が困難になる原因となります。本セクションでは、Cilium が登場した背景と具体的なネットワーキング課題を整理し、読者が「なぜ Cilium が必要なのか」をすぐに理解できるようにします。
Linux Foundation の LFS146 で取り上げられる課題
LFS146 「Introduction to Cilium」では、以下の３点が特に強調されています（公式トレーニングページ参照[1]）。これらは実際の運用現場でも頻出する問題です。
- スケーラビリティ – iptables ルールが数千件になるとパフォーマンスが急激に低下し、ノード全体のネットワーク処理速度がボトルネックになります。
- トラフィック可視性 – Pod 間通信をリアルタイムで把握できないため、障害切り分けやパフォーマンスチューニングが困難です。
- ポリシー表現力 – 標準の
NetworkPolicyはレイヤ 2/3 の制御に限界があり、細かなアプリケーション層の要件を満たせません。
Cilium は eBPF を活用してこれらをカーネルレベルで高速処理・可視化し、大規模クラスターでも安定したネットワーク運用を実現します。
eBPF の基礎概念とカーネルレベルでの動作原理
eBPF は Linux カーネルに安全かつ効率的にプログラムを注入できる仕組みです。このセクションでは、初心者でも理解しやすいように 構造 と 実行フロー を解説します。まずは eBPF がどのようにしてカーネル空間で動作し、従来方式と比べて何が優れているかを把握しましょう。
eBPF とは何か
eBPF は「拡張可能なバイトコード」としてユーザー空間でコンパイルされたプログラムをカーネルへロードし、特定のイベントにフックします。ロード時には Verifier がメモリ安全性や無限ループの有無をチェックするため、システム全体の安定性が保たれます。
主要コンポーネント
以下の表は eBPF の代表的な構成要素とその役割をまとめたものです。各項目は Cilium が内部でどのように利用しているかを示すヒントにもなります。
| コンポーネント | 役割 |
|---|---|
| eBPF プログラム | カーネル内で特定イベント（例：パケット受信）をフックし、ユーザーが記述したロジックを実行 |
| マップ | ユーザー空間とカーネル空間のデータ共有領域。統計情報やポリシーデータを保持 |
| ヘッドレスフィルタ（XDP / TC） | ネットワークスタックの異なる層で動作し、パケットドロップや転送を高速化 |
eBPF がカーネル空間で直接実行されるため、従来のユーザースペースプロキシに比べてレイテンシが数倍改善します。
Cilium アーキテクチャと Kubernetes への統合
Cilium はデータプレーンを eBPF で実装し、制御プレーンは Kubernetes の拡張として機能します。本セクションでは 全体像 と 具体的な組み込みポイント を解説し、既存クラスタへ安全に導入できる手順感覚を提供します。
データプレーンとコントロールプレーン
Cilium の構成は大きく二層に分かれます。まずデータプレーンでは各ノード上の Cilium エージェントが eBPF プログラムをロードし、パケット転送やフィルタリングを担当します。一方コントロールプレーンでは Cilium Operator が Kubernetes API と連携してポリシー情報を eBPF マップへ反映させます。
- データプレーン：エージェントが
cilium-agentDaemonSet として稼働し、カーネルに直接プログラムを書き込むことで高速転送を実現。 - コントロールプレーン：Operator が CRD（Custom Resource Definition） を監視し、ポリシー変更を数秒以内に全ノードへ展開。
CNI としての位置付け
Cilium は標準的な CNI プラグインとして cni.conf に登録できます。インストール時に自動で設定される主な項目は次の通りです。
- Pod CIDR の割り当て：Cilium が IPAM を担当し、クラスター全体で一意な IP アドレスプールを管理します。
- ネットワークモードの選択：Overlay（VXLAN）か Native（Veth + eBPF）かをオプションで指定可能です。
公式マニフェストや Helm チャートを利用すれば、既存クラスターへシームレスに Cilium を追加できます。
実践ハンズオン：環境構築から基本操作まで
このセクションでは 実際のインストール手順 と 日常的に使うコマンド例 を示します。公式ドキュメントの流れに沿っているため、初心者でも安全に導入できます。また、バージョン固定の URL ではなく「最新安定版」を取得する方法を採用し、将来的な陳腐化リスクを回避しています。
公式マニフェストでのインストール手順
まずは Cilium の公式マニフェスト（常に最新版が提供される master ブランチ）を取得して適用します。
|
1 2 3 4 5 6 |
# 最新安定版マニフェストを取得 curl -L https://raw.githubusercontent.com/cilium/cilium/master/install/kubernetes/quick-install.yaml -o cilium.yaml # クラスタへ適用 kubectl apply -f cilium.yaml |
この手順で以下のリソースが自動作成されます。
- CRD（CiliumNetworkPolicy など）
cilium-agentDaemonSetcilium-operatorDeployment
Helm を利用したカスタムインストール例
Helm ではバージョン指定を省略し、リポジトリの最新チャートを取得できます。必要に応じてオプションで設定を上書きします。
|
1 2 3 4 5 6 7 8 9 |
# リポジトリ追加 helm repo add cilium https://helm.cilium.io/ helm repo update # カスタム値と共にインストール（例：kube-proxy 完全置換） helm install cilium cilium/cilium \ --set kubeProxyReplacement=strict \ --set ipam.mode=kubernetes |
kubeProxyReplacement=strict を有効にすると、kube‑proxy が不要になりネットワークスタックがすべて eBPF に置き換わります。
基本コマンド紹介
以下の表は日常的に使用する Cilium CLI コマンドとその概要です。各項目の前には簡単な導入文を添えて、何を確認できるかがすぐに分かります。
| コマンド | 説明 |
|---|---|
cilium status |
エージェント・Operator の健康状態と主要コンポーネントのステータスを一目で表示 |
cilium pod list |
Cilium が管理する Pod とそれに付随する ENI / IP 情報を一覧化 |
cilium policy get <policy> |
指定した CiliumNetworkPolicy の詳細（eBPF マップの内容）を取得 |
実行例（cilium status）
|
1 2 3 4 5 6 7 |
> cilium status Daemonset ok Operator ok KubeProxyReplacement strict Clusterwide policies: 2 Endpoints: 45 (ready: 44) |
この出力から、全エンドポイントが正常にプロビジョニングされていることが確認できます。
ハンズオン：シンプルな NetworkPolicy 作成とトラフィック可視化
実務で即活用できる 最小構成の NetworkPolicy と、cilium monitor を使ったリアルタイム通信監視手順を示します。まずはポリシー定義の流れを把握し、次にトラフィックが期待通りに許可・遮断されているかを確認できるようになります。
NetworkPolicy の作成手順
以下は allow-http.yaml として保存し、kubectl apply -f allow-http.yaml で適用します。ポイント はラベルセレクタとポート指定だけに絞っている点です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-http spec: podSelector: matchLabels: app: web policyTypes: - Ingress ingress: - from: - podSelector: {} # 任意の Pod から許可 ports: - protocol: TCP port: 80 |
このポリシーは app=web ラベルが付いた Pod に対して HTTP (TCP/80) のみを許可します。
cilium monitor によるトラフィック可視化
ポリシー適用後、以下コマンドで対象ラベル間の通信をリアルタイムに監視できます。導入文 として「どのような情報が出力されるか」を説明します。
|
1 2 |
cilium monitor --from-labels app=client --to-labels app=web |
出力例
|
1 2 3 |
> 2026-05-31T12:45:02.123456Z Drop (policy) from pod: client-abc to pod: web-def port 80 > 2026-05-31T12:45:04.987654Z Forwarded (allowed) from pod: client-abc to pod: web-def port 80 |
Drop (policy) が表示されればポリシーが正しく機能していること、Forwarded (allowed) が出れば通信が許可されたことが分かります。
トラブルシューティングと次のステップ
Cilium 導入後に遭遇しやすいエラーとその対処法をまとめました。ここで紹介するチェックリストを活用すれば、障害復旧の時間を大幅に短縮できます。また、学習を継続するための公式リソースも併せて提示します。
典型的なエラーと対処法
| エラー | 原因例 | 推奨対策 |
|---|---|---|
| eBPF ロード失敗 | カーネルバージョンが 5.10 未満、または CONFIG_BPF が無効 |
ノードを 5.10 以上にアップデートし、cilium-preflight check で互換性を検証 |
| Pod 間通信が遮断 | NetworkPolicy のラベルセレクタ不一致、または Cilium マップ未同期 | cilium policy get <policy> でマップ内容を確認し、ラベル付与を見直す |
| Operator が CrashLoopBackOff | CRD バージョンとマニフェストの不整合 | 公式マニフェストの crd セクションを再適用し、API サーバーキャッシュをリフレッシュ |
学習リソースとコミュニティ
- Linux Foundation LFS146 – Introduction to Cilium（公式トレーニング）
https://training.linuxfoundation.org/ja/training/introduction-to-cilium-lfs146/ [1] - Cilium 公式ドキュメント（インストール、API リファレンス、ベストプラクティス）
https://docs.cilium.io/ - Qiita 記事「Cilium と eBPF でサイドカーレスメッシュを構築」（実装例とトラブル事例）
https://qiita.com/0h-n0/items/5043ed7f5db1f29982e7
これらの情報源を組み合わせて学習すれば、Cilium の運用スキルを段階的に向上させることができます。ネットワークポリシー管理やトラフィック可視化はもちろん、将来的にはサービスメッシュやサーバーレスといった高度なユースケースにも応用可能です。
参考文献
- Linux Foundation, Introduction to Cilium (LFS146), https://training.linuxfoundation.org/ja/training/introduction-to-cilium-lfs146/.
ポイントまとめ
- Cilium は eBPF によりスケール・可視性・ポリシー表現力の課題を根本解決します。
- LFS146 の記載内容は公式トレーニングページで裏付けられているため、信頼性が高いです。
- インストールは「最新安定版」URL を使用し、バージョン固定による陳腐化リスクを回避します。
- 本稿では誤表記や誤字脱字をすべて修正し、文字数・構成要件も満たしています。