Ciliumとは？eBPFベースのKubernetes CNIの仕組みとCalico比較・導入判断を解説

Cilium（シリウム）は、LinuxカーネルのeBPFを土台にしたKubernetes向けのCNI（Container Network Interface）です。Pod間の通信経路を担うだけでなく、Hubbleによる通信の可視化、NetworkPolicyやL7ポリシーによるセキュリティ、サイドカー無しのサービスメッシュまでを1つのソフトウェアで扱えます。この記事では、実装者の目線でCiliumがCNIとして何をするのか、kube-proxyやiptablesとの関係、Calicoとの設計差、そして自社のKubernetes基盤に採用すべきか見送るべきかの判断軸を、公式ドキュメントの一次情報にもとづいて整理します。

まとめ：CiliumはeBPFで動くKubernetes向けCNI

CiliumはCNCFのGraduatedプロジェクト（2023年に卒業）で、eBPFをデータプレーンの中心に据えたKubernetes向けのネットワーク基盤です。従来のiptablesベースのkube-proxyを置き換え、Pod数が増えても性能が劣化しにくい経路制御を提供します。核になる価値は3つで、eBPFによるネットワーク、Hubbleによる可観測性、NetworkPolicyによるセキュリティが同じ基盤の上に載ります。

採用の判断はクラスタ規模と要件で分かれます。数十〜数百ノード規模でマルチクラスタや細かい通信制御、L7可視化が要るなら候補に入ります。逆に数ノードの単一クラスタで既定のCNIが足りているなら、Ciliumの運用コストは過剰投資になりがちです。以下では仕組み、Calicoとの違い、採用と見送りの線引きを順に見ていきます。

eBPFベースのCNIとしてのCiliumの立ち位置と主な役割

まずCiliumがKubernetesのどの層を担うのかを押さえます。Kubernetesは「Podをどのノードで動かすか」までは決めますが、Pod同士をどうつなぐかはCNIプラグインに委ねます。Ciliumはこの接続層を、eBPFで書き換えたのが出発点です。コンテナの並べ方そのものについては、Kubernetesが自社に必要かの判断を別記事で扱っています。

kube-proxyを置き換えるデータプレーンとしてのCilium

標準のKubernetesでは、Serviceの仮想IPから実際のPodへの振り分けをkube-proxyが担い、その実体はiptablesまたはIPVSのルールです。CiliumはeBPFでこの処理を肩代わりし、kube-proxyを無効化する構成（kube-proxy replacement）を取れます。Serviceやエンドポイントが数千規模になると、iptablesはルールが線形に膨らんで処理が重くなります。eBPFはカーネル内のハッシュ表で引くため、規模が増えても遅延が伸びにくいのが設計上の狙いです。

この置き換えは全部か無かではありません。部分的な有効化もでき、既存クラスタから段階的に移せます。

iptablesに依存しないeBPFデータプレーンの動作の仕組み

eBPFは、カーネルを再ビルドせずに検証済みの小さなプログラムをカーネル内で動かす仕組みです。Ciliumはパケットがネットワークインターフェースに届いた地点でeBPFプログラムを走らせ、ルーティングやポリシー判定、負荷分散をカーネル空間で完結させます。ユーザー空間との往復が減るぶん、オーバーヘッドが小さくなるのが利点です。eBPF自体の成り立ちはeBPFがLinuxカーネルで動く仕組みで詳しく解説しています。

Ciliumは各Podに識別子（identity）を割り当て、IPアドレスではなくこの識別子でポリシーを判定します。PodのIPが入れ替わっても、ラベルに紐づく識別子は保たれるため、動的な環境でも制御が破綻しにくくなっています。

Ciliumが担うネットワーク・可観測性・セキュリティの3領域

Ciliumを単なるCNIと捉えると評価を見誤ります。1つのデータプレーンの上に、通信・可視化・防御が積み重なっているのが特徴です。ここではネットワーク以外の2領域を掘り下げます。

Hubbleが提供するネットワークフロー可視化と依存関係把握

HubbleはCiliumに同梱される可観測性コンポーネントで、eBPFが見ているフローをそのまま吸い上げます。どのPodからどのPodへ、どのポートで、許可されたか拒否されたかを、アプリ側にエージェントを追加せず記録できるのが強みです。Hubble UIを入れると、サービス間の依存関係をグラフで追え、障害時に「どの通信が落ちたか」を切り分けやすくなります。マイクロサービスが増えて通信経路が把握しづらくなった現場で効きます。

NetworkPolicyとL7ポリシーで実現する通信の制御

Ciliumは標準のNetworkPolicyに加え、独自拡張のCiliumNetworkPolicyでL3からL7までを制御します。IPやポート単位だけでなく、HTTPのメソッドやパス、gRPCのサービス名、Kafkaのトピックといったアプリ層の条件で許可・拒否を書けるのが差分です。たとえば「このサービスへのGETは許すがDELETEは拒否する」といった規則を、アプリを改修せずに敷けます。ゼロトラストに近い通信制御を、ネットワーク層で実現する使い方が中心になります。

サイドカーを使わないサービスメッシュとクラスタ間メッシュ機能

従来のサービスメッシュは、各Podにプロキシを相乗りさせるコンテナのサイドカーパターンで実現してきました。Ciliumはこの役割をノードのeBPFに寄せ、サイドカー無しでメッシュ機能を提供します。Pod単位のプロキシが減るぶん、メモリ消費とレイテンシを抑えられるのが利点です。メッシュ全般の考え方はサービスメッシュの仕組みと導入判断にまとめています。加えてCluster Meshで複数クラスタをまたいだサービス検出と通信ができ、地理分散やクラスタ移行時のトラフィック切り替えに使えます。

CiliumとCalicoの違いと導入時に見る選定基準と判断軸

CNI選定でCiliumと並んで挙がるのがCalicoです。両者はどちらも成熟したCNIですが、設計思想と得意領域が異なります。ここを取り違えると、要らない機能に運用コストを払うことになります。

データプレーン方式で見るCiliumとCalicoの設計の差

最大の分岐点はデータプレーンです。CiliumはeBPFを前提に組まれています。Calicoは長くiptablesベースで実績を積み、後からeBPFデータプレーンを選べるようになりました。つまりeBPFを主軸にするならCilium、iptablesの枯れた挙動を残しつつ必要ならeBPFへ寄せたいならCalico、という住み分けになります。両者ともBGPによる経路広告に対応しますが、Ciliumはトンネル方式とネイティブルーティングの両構成を持ちます。

機能比較表で見る可観測性とセキュリティとマルチクラスタ対応の差

機能の重心を並べると違いが見えます。数値は2026年時点の各公式ドキュメントを基準にした概観で、細部はバージョンで変わります。

可視化やL7制御、マルチクラスタを一体で扱いたいならCiliumが手数が少なく済みます。逆にネットワークポリシーの適用が主目的で、既存のiptables運用を大きく変えたくないならCalicoの方が移行の摩擦は小さくなります。

Ciliumの採用要件と過剰投資となる見送り場面の切り分け方

ここは判断を言い切ります。Ciliumは強力ですが、全てのKubernetes環境に要るわけではありません。要件から見て採る場面と、見送るべき場面を条件付きで分けます。

Ciliumの採用が見合うクラスタ規模とネットワーク上の要件

採用が見合うのは、次のいずれかに当てはまるときです。Serviceやエンドポイントが数千規模でkube-proxyのiptablesが性能の足かせになっている。複数クラスタをまたいだ通信やフェイルオーバーが要る。HTTPやgRPC単位の通信制御と、その可視化を監査や事故対応で求められる。これらは既定のCNIでは手当てが難しく、Ciliumの設計がそのまま効く領域です。自前でこの規模のKubernetes基盤を設計・運用するなら、CNI選定を含めてWebシステム開発の相談として設計段階から詰めておくと後戻りが減ります。

小規模な単一クラスタでCiliumが過剰投資になりやすい条件

逆に、数ノードの単一クラスタで、通信量も少なく、マネージドサービスの既定CNIで不足が出ていないなら、Ciliumの導入は過剰投資になりやすいと考えます。eBPFやカーネル版数の前提を満たす運用体制、Hubbleやポリシーを扱える人員、アップグレード時の検証コストが継続して乗るためです。可視化やL7制御を今すぐ必要としない段階で先回りして入れると、機能の大半を使わないまま運用負荷だけが残ります。まず既定CNIで運用し、性能や可視化の課題が実際に顕在化してから移行を検討する順序が現実的です。

Cilium導入前に確認するカーネルとマネージドK8sの前提

最後に、導入前に潰しておく前提条件を整理します。ここを飛ばすと、入れてから機能が動かないという事態になります。

Ciliumが求めるLinuxカーネルの版数と機能の対応関係

CiliumはeBPFを使うため、ノードのLinuxカーネル版数が前提です。基本機能は比較的広い版数で動きますが、kube-proxy replacementや帯域制御、一部のL7機能はより新しいカーネルを求めます。2026年時点の公式ドキュメントでは、機能ごとに必要な版数が表で示されており、5.x系以降を推奨する項目が多くなっています。導入前に、動かしたい機能とノードのカーネル版数の対応を必ず突き合わせてください。マネージドサービスではカーネルを自由に選べないことがある点にも注意が必要です。

マネージドKubernetesでCiliumを使う際の対応状況

マネージドKubernetesでは、Ciliumの扱いがサービスごとに異なります。GoogleのGKEはDataplane V2としてCiliumを基盤に取り込み、AzureのAKSはAzure CNI Powered by Ciliumの構成を用意しています。AWSのEKSは既定と別に自前でCiliumを入れる形が中心です。いずれも2026年時点の状況で、対応範囲は更新されます。マネージド環境では、CNIの差し替えがサポート対象か、既定のネットワーク機能とどう共存するかを、事前に各サービスのドキュメントで確認しておくと安全です。

よくある質問

Ciliumの検討で実際に挙がる質問を、実装の観点からまとめます。

Ciliumとは何のためのソフトウェアですか？

KubernetesでPod間の通信を担うCNIプラグインの1つで、eBPFを土台にしています。単なる接続だけでなく、Hubbleによる通信の可視化、NetworkPolicyやL7ポリシーによる制御、サイドカー無しのサービスメッシュまでを同じ基盤で扱える点が特徴です。CNCFのGraduatedプロジェクトとして開発が続いています。

CiliumとCalicoはどちらを選ぶべきですか？

可視化やL7の通信制御、マルチクラスタを一体で扱いたいならCiliumが手数少なく収まります。ネットワークポリシーの適用が主目的で、既存のiptables運用を大きく変えたくないならCalicoが移行しやすいです。どちらもeBPFデータプレーンを持てますが、Ciliumはそれを前提に、Calicoは選択肢として提供する設計の差があります。

CiliumはeBPFがないと動きませんか？

CiliumはeBPFを前提に設計されているため、eBPFが使えるLinuxカーネルが実質の必須条件です。ただし要求される版数は機能によって幅があり、基本的な接続は広い版数で動き、kube-proxy replacementなど一部の機能は新しいカーネルを求めます。導入前にノードのカーネル版数を確認してください。

Hubbleだけを単体で導入できますか？

HubbleはCiliumの可観測性コンポーネントで、Ciliumのデータプレーンが吸い上げたフローを見せる仕組みです。そのためHubble単体ではなく、Ciliumを入れたうえで有効化する形になります。CLIだけの軽い使い方から、Hubble UIでグラフ表示する使い方まで段階的に広げられます。

Ciliumの導入にkube-proxyは必要ですか？

必須ではありません。CiliumはeBPFでkube-proxyの役割を肩代わりでき、無効化する構成を取れるのが特徴です。一方で、まずkube-proxyを残したまま部分的に導入し、段階的に置き換える運用もできます。既存クラスタへ入れる場合は、いきなり全置換せず段階移行する方が検証しやすくなります。

関連記事

• eBPFとは？Linuxカーネルを拡張する仕組みと可観測性・ネットワーク：Ciliumの土台になるeBPFの動作原理を、カーネルの観点から詳しく解説しています。
• サービスメッシュとは？サイドカー方式の仕組みと導入判断：Ciliumが提供するサイドカー無しメッシュの前提となる、メッシュ全般の考え方を整理しています。
• サイドカーとは？コンテナのサイドカーパターンを仕組みから解説：Ciliumが置き換えるサイドカー方式そのものの仕組みと、その導入判断を扱っています。
• コンテナオーケストレーションとは？Kubernetesの役割と判断：CiliumがCNIとして支えるKubernetesを、自社に必要かの判断軸から解説しています。