結論から言えば、CiliumがIstioよりも常に優れているわけではない。しかし、Kubernetesネットワーキング、セキュリティポリシー、ロードバランシング、可観測性、そしてサービスメッシュを一つのプラットフォームに統合しようとする組織にとっては、Ciliumがよりシンプルで一貫性のある選択肢となり得る。
サービスメッシュを検討する際、よく「IstioとCiliumのどちらを選ぶべきか？」という質問に出会います。
この質問にはまず前提が必要です。IstioとCiliumは出発点から異なります。Istioはサービス間の通信を制御するサービスメッシュとして出発し、CiliumはeBPFベースのKubernetes CNIとネットワークセキュリティプラットフォームとして出発し、サービスメッシュ領域まで拡張しました。
したがって、両者は完全に同じ製品ではありません。IstioはCNIの上に構築されるサービスメッシュであり、CiliumはCNI自体でありながら、ネットワークポリシー、kube-proxyの代替、可観測性、L7プロキシ機能まで提供できます。
それでも、特定の環境ではCiliumがより良い選択肢となります。特にKubernetes中心のインフラで既にCiliumをCNIとして使用しており、トラフィックのほとんどがL3・L4ポリシーで十分であり、必要な区間にのみL7機能を適用したい場合です。
この記事は「CiliumがIstioよりも無条件に優れている」という主張ではありません。どのような条件でCiliumの統合構造が実質的な利点となり、どのような条件では依然としてIstioがより適しているのかを区別することが目的です。
まず整理すること：CiliumとIstioは何が違うのか
両製品の最大の違いは担当範囲です。
Istioは現在、2つのデータプレーン方式を提供しています。伝統的なサイドカーモードは各Podの隣にEnvoyを配置し、アンビエントモードはノードごとのL4プロキシであるztunnelと、必要に応じて使用する名前空間単位のL7ウェイポイントプロキシに機能を分けます。 Istio データプレーンモード 公式ドキュメント
この違いを理解することで、「サイドカーがないからCiliumは無条件に軽い」とか「eBPFを使うからL7もすべてカーネルで処理する」といった誇張を避けることができます。
理由1：CNIとサービスメッシュを一つのプラットフォームに集約できる
Ciliumの最も現実的な利点は、単純なパケット処理性能よりも統合にあります。
一般的なKubernetes環境で別々の製品を組み合わせると、次のような構成要素が生じる可能性があります。
- CNIプラグイン
- kube-proxy
- Kubernetes NetworkPolicy実装
- サービスメッシュ
- IngressまたはGateway APIコントローラー
- ネットワークフロー観測ツール
Ciliumは、これらのうち複数の役割を一つのプラットフォームで担当できます。CNIとネットワークポリシーは基本であり、eBPFベースのkube-proxy代替、Gateway API、Hubble可観測性、そして選択的なL7プロキシを一緒に運用できます。
Ciliumのkube-proxy代替モードは、ClusterIP、NodePort、LoadBalancer、およびexternalIPsサービス処理をeBPFで実装します。 Cilium kube-proxy replacement 公式ドキュメント
この統合がもたらす利点は、「プロセス数が無条件に少ない」という単純な話ではありません。障害を分析する際に、CNI、サービスNAT、ネットワークポリシー、サービスメッシュの境界を複数の製品間で追跡する必要がある負担が軽減されるという意味です。
特にプラットフォームチームがKubernetesネットワーク全体を責任持つ場合、データパス、ポリシーモデル、観測ツールが一つの製品群として連携することは、運用上大きな利点です。
理由2：すべてのトラフィックにL7プロキシを付与する必要がない
サービスメッシュを導入したからといって、すべての通信にHTTPヘッダーベースのルーティング、再試行、分散トレーシングが必要なわけではありません。
データベース接続、内部TCPプロトコル、単純なサービス検出、多数のバックエンド通信は、L3・L4セキュリティポリシーとロードバランシングだけで十分な場合があります。このようなトラフィックまでPodごとにL7プロキシを通過させると、プロキシの数、設定のデプロイ対象、リソース予約量がアプリケーションのレプリカ数に応じて増加します。
CiliumはL3・L4パスをeBPFで処理し、HTTPポリシーやGateway APIのようにL7解釈が必要なトラフィックのみをノードローカルのEnvoyに送ります。CiliumのL7ポリシーはノードローカルのEnvoyインスタンスを通過し、EnvoyはCiliumエージェント内で実行することも、別途DaemonSetとして運用することもできます。 Cilium Envoy 公式ドキュメント, Cilium L7 Policy 公式ドキュメント
この構造は次の条件で有利です。
- サービス数とPodレプリカ数が多い。
- ほとんどの通信はL4ポリシーで十分である。
- 一部のAPIと外部エントリポイントにのみL7機能が必要である。
- アプリケーションPodのサイドカー注入と再起動を減らしたい。
ただし、比較対象がIstioサイドカーである場合に利点が最も大きいです。Istioアンビエントも各Podのサイドカーをなくし、ノードごとのztunnelと選択的なウェイポイントでL4とL7を分離します。Istioの公式ドキュメントも、アンビエントがサイドカー方式のリソースコストと運用負担を軽減するために設計されたと説明しています。 Istio ambient 概要
したがって、2026年の正しい比較は「Cilium対Istioサイドカー」で終わるべきではありません。「CiliumのeBPF+ノードEnvoy構造とIstioアンビエントのztunnel+ウェイポイント構造のうち、私たちの組織にどちらがより適しているか」を見るべきです。
理由3：ネットワークポリシーと可観測性が同じデータから出発する
Kubernetesネットワーク障害で最も答えるのが難しい質問は単純です。
このリクエストはどこからどこへ行き、許可されたのか、拒否されたとすればどのポリシーによるものか？
CiliumのHubbleは、CiliumとeBPFデータパスで観測されたフローを使用します。ノード、クラスター、ClusterMeshの範囲でサービス間のフローを確認でき、Hubble UIはL3・L4だけでなく、条件が満たされればL7サービスマップも提供します。 Hubble 公式ドキュメント
この統合の利点は、セキュリティポリシーと観測結果が異なる収集レイヤーにないことです。
- どのCiliumセキュリティアイデンティティが通信したか
- どのポートとプロトコルを使用したか
- ポリシーによって転送されたか、拒否されたか
- DNSまたはHTTPレベルでどのようなフローが発生したか
- どのノードとワークロードで問題が発生したか
この情報を同じ運用ツールで連携できます。
Istioもメトリクス、分散トレーシング、アクセスログを豊富に提供します。特にアプリケーションレベルの遅延、エラー率、呼び出し関係を分析するのに強力です。 Istio Observability 公式ドキュメント
違いは観測の出発点です。Istioの中心はプロキシが見たサービスリクエストであり、Hubbleの中心はCNIとeBPFデータパスが見たネットワーク・セキュリティフローです。ネットワークポリシーのデバッグが重要なプラットフォームチームにとっては、Hubbleのアプローチがより直接的である可能性があります。
理由4：Kubernetes Gateway APIを中心に運用モデルを合わせられる
古いKubernetesインフラは、製品ごとに異なるIngressアノテーションと専用CRDを使用していました。その結果、同じHTTPルーティングであってもプラットフォームを変更すると設定を再作成する必要がありました。
CiliumはKubernetes Gateway APIをデータプレーンと連携させます。現在の安定版ドキュメントでは、Gateway API v1.4.1のGatewayClass、Gateway、HTTPRoute、GRPCRoute、ReferenceGrantなどをサポートし、Core conformance testに合格したと明記されています。 Cilium Gateway API 公式ドキュメント
プラットフォームチームがGateway APIを標準のエントリポイントとして採用すれば、次の領域を一つのポリシー言語に近づけて整理できます。
- 外部Ingress
- サービス間HTTPルーティング
- gRPCルーティング
- トラフィック分割
- ヘッダー修正
- TLS終端
もちろん、IstioもGateway APIとアンビエントウェイポイントを積極的に使用しています。したがって、Gateway APIのサポート自体だけでCiliumの勝利を宣言することはできません。
Ciliumがより優れているのは、既にCiliumをCNIとロードバランサーとして使用しており、同じプラットフォームでGateway APIまで連携させたい場合です。新しいメッシュ専用APIと別途データプレーンを追加する代わりに、既存のネットワーク運用モデルを拡張できるためです。
理由5：プラットフォームチームが管理すべき境界を減らせる
Istioサイドカー環境では、アプリケーションのデプロイとプロキシのライフサイクルが強く結合しています。サイドカー注入設定が変更されるとPodの再起動が必要になることがあり、各ワークロードのCPUとメモリ要求量にプロキシを反映させる必要があり、アプリケーションの問題とEnvoyの問題を一緒に検討しなければなりません。
CiliumのL7 Envoyはノード単位の共有コンポーネントとして実行できます。アプリケーションのレプリカごとにプロキシコンテナを付与しないため、プラットフォームコンポーネントのライフサイクルをアプリケーションPodと分離しやすくなります。
しかし、共有プロキシには反対側のトレードオフもあります。
- ノードプロキシ障害の影響範囲が大きくなる可能性がある。
- 複数のワークロードのL7トラフィックが同じプロキシリソースを競合する可能性がある。
- ノード単位の容量計画と障害隔離が必要である。
- L7トラフィックは結局Envoyの処理コストを支払う。
したがって、「サイドカーがないからコストが0」ではなく、「コストと運用単位がPod別からノード別へ移動する」と理解する方が正確です。
Istioアンビエントも同様にプロキシのライフサイクルをプラットフォームチーム側へ移動させます。公式比較ドキュメントでは、アンビエントでワークロードをメッシュに追加する際にPodの再起動が不要であり、ウェイポイントを通常のKubernetes Deploymentのように拡張できると説明しています。 Istio sidecarとambient比較
結局、Ciliumの本当の優位性は「サイドカーがない」一つだけではなく、サイドカーのない構造をCNIとネットワークポリシーまで含んだ単一プラットフォームで運用できるという点にあります。
では、Istioがより優れているのはいつか
Ciliumの利点を正しく語るには、Istioがより優れている条件も明確にする必要があります。
1. 成熟したmTLSとサービスアイデンティティが最優先の場合
Istioは標準のmTLS、認証、認可をサービスメッシュの核となる機能として長年運用してきました。Kubernetes外のVM、複数のクラスター、異なるCNIを含む環境でも一貫したメッシュを構築することが主要な目標です。 Istioを選択する理由
一方、Cilium 1.19.6の公式ドキュメントでは、相互認証はベータ版であり、機能がまだ完成していないと明記されています。単一のトラストドメインを持つマルチクラスター構成も現在サポートしておらず、外部mTLSソリューションとの互換性にも制限があります。 Cilium Mutual Authentication 制限事項
mTLSとワークロードアイデンティティが購入決定の最初の基準である場合、Istioがより保守的な選択肢です。
2. 複雑なL7トラフィック制御が核心である場合
IstioはVirtualServiceとDestinationRuleを中心に、次の機能を幅広く提供します。
- ヘッダーとURIベースのルーティング
- 比率ベースのカナリアとA/Bテスト
- リクエストごとのタイムアウトと再試行
- サーキットブレーキングと外れ値検出
- フォールトインジェクション
- トラフィックミラーリング
- 外部サービスとVMを含むServiceEntry
これらの機能は長期間Envoyデータプレーンとともに運用されてきました。 Istio Traffic Management 公式ドキュメント
CiliumもGateway APIとCiliumEnvoyConfigでL7トラフィック制御の範囲を広げていますが、複雑なアプリケーションのトラフィックポリシーとEnvoy拡張エコシステムが核心である場合、Istioの方がより馴染み深く、機能が豊富です。
3. CNIと独立したメッシュが必要な場合
Ciliumの統合は利点であると同時に結合でもあります。Ciliumサービスメッシュ機能は、Cilium CNIとeBPFデータパスを前提とします。
逆にIstioはCNIと分離されたサービスメッシュであるため、クラスターごとにCNIが異なる場合や、KubernetesとVMを一緒に連携させる場合、特定のネットワーク実装に依存しない必要がある場合に有利です。
4. Istioアンビエントが既に要件を満たしている場合
「サイドカーが嫌だ」という理由だけで、既存のIstioを捨てる必要はありません。
Istioアンビエントは、ノードごとのztunnelでmTLS、L4認証、テレメトリーを処理し、L7が必要な名前空間にウェイポイントを追加します。既存のIstioポリシーと運用経験を維持しながらサイドカーのコストを削減することが目的であれば、アンビエントへの移行がCiliumの再構築よりも現実的である可能性があります。 Istio ambient 公式概要
意外な答え：CiliumとIstioを一緒に使うこともできる
両製品を必ずどちらか一つだけ選択しなければならないわけではありません。
Ciliumは高性能CNI、eBPF kube-proxy代替、NetworkPolicy、Hubbleを担当し、IstioはmTLS、L7トラフィック管理、サービスメッシュを担当するように構成できます。
Ciliumの公式ドキュメントには、IstioサイドカーとアンビエントモードをCiliumネットワーク上で使用する統合方法が別途提供されています。 CiliumとIstio統合 公式ドキュメント
この構成は次の状況で妥当です。
- CiliumネットワーキングとHubbleを維持したい。
- Istioの成熟したmTLSとL7ポリシーが必要である。
- 一度にネットワークとメッシュの両方を交換したくない。
- 組織のネットワークチームとアプリケーションプラットフォームチームが役割を分離している。
もちろん、構成要素が増えるため、障害点とアップグレードの組み合わせも多くなります。「両方使えば最高」ではなく、統合によって得られる機能が運用上の複雑さを上回る場合にのみ選択すべきです。
選択基準を一枚にまとめると
| 要件 | Ciliumがより適している | Istioがより適している |
| 既にCilium CNIを使用中 | はい | 別途メッシュレイヤーの追加が必要 |
| kube-proxy代替とネットワークポリシー統合 | 強み | 担当範囲外 |
| L3・L4中心、一部のみL7 | 強み | アンビエントも良い代替案 |
| Hubbleベースのネットワーク・セキュリティフロー分析 | 強み | プロキシ中心の可観測性を提供 |
| 複雑な再試行、タイムアウト、フォールト、ミラーリング | 制限を検討する必要がある | 強み |
| 成熟したサービスmTLSと認証 | ベータ状態を検討する必要がある | 強み |
| VMと異種・マルチクラスターメッシュ | 制限を検討する必要がある | 強み |
| CNI独立性 | 低い | 高い |
| Gateway API中心のKubernetes運用 | 強み | 同様にサポート、要求機能の比較が必要 |
| Podごとのサイドカー排除 | 基本構造 | アンビエントで可能 |
—
実際に導入する前に何を測定すべきか
製品紹介資料だけを見て決定すると、「eBPFだから速い」とか「Envoyだから重い」といった単純な結論に陥りがちです。
同じワークロードとポリシーで小さな検証環境を構築し、次の項目を測定することをお勧めします。
性能とコスト
- L4とL7トラフィックそれぞれのp50・p95・p99遅延時間
- 1秒あたりのリクエスト数と接続数
- ノードとPodごとのCPU・メモリ使用量
- Envoy、ztunnel、ウェイポイントのリソース使用量
- 障害発生時およびローリングアップデート中の接続維持の有無
運用複雑度
- インストールされるDaemonSet、Deployment、CRDの数
- アプリケーションデプロイ時のサイドカーまたはアノテーションへの依存性
- ポリシー変更が実際のデータプレーンに反映される時間
- アップグレード時のPod再起動とサービスへの影響
- 障害原因を特定するために必要なツールと平均時間
機能適合性
- 必要なL7プロトコルとルーティングルールのサポート状況
- mTLS、アイデンティティ、認証の要件
- マルチクラスター、マルチネットワーク、VMのサポート状況
- Gateway APIの適合性と必要な拡張機能
- 監査ログと分散トレーシングの要件
最終的な決定は、ベンチマークの数字一つではなく、チームが実際に運用する機能と失敗モードに基づいて下されるべきです。
結論：Ciliumの優位性は速度よりも統合にある
IstioよりもCiliumが優れている理由を一句でまとめると次のようになります。
Kubernetesネットワークの出発点であるCNIから、セキュリティポリシー、サービスロードバランシング、可観測性、そして選択的なL7処理までを、一つのeBPFベースの運用モデルで連携できるからである。
この利点は、既にCiliumを使用しており、Kubernetesがインフラの中心であり、L3・L4トラフィックが多く、必要な箇所にのみL7機能を適用したい組織で最も大きいです。
逆に、成熟したmTLS、複雑なL7トラフィック管理、VMと異種マルチクラスターが核心である場合、Istioがより適している可能性があります。Istioアンビエントがサイドカーの欠点を大幅に軽減したという事実も考慮に入れるべきです。
したがって、質問は「CiliumはIstioよりも速いか？」で終わるべきではありません。
私たちの組織が実際に答えるべき質問はこれです。
ネットワークとサービスメッシュを一つのプラットフォームに統合することがより重要なのか、それともネットワークと独立した成熟したL7サービスメッシュがより重要なのか？
最初の質問であればCiliumが有力です。2番目の質問であればIstioが依然として強力です。そして、両方の要件が同時に大きい場合は、Cilium CNIの上にIstioを運用する組み合わせも十分に検討する価値があります。
参考にした公式資料
- Cilium Service Mesh
- Cilium Kubernetes Without kube-proxy
- Cilium Envoy
- Cilium Layer 7 Policies
- Cilium Hubble
- Cilium Gateway API Support
- Cilium Mutual Authentication
- Cilium Integration with Istio
- Istio Sidecar or Ambient
- Istio Ambient Overview
- Istio Traffic Management
- Istio Observability
- Why Choose Istio
コメントを残す