Cilium vs Istio Ambient：サイドカーレスサービスメッシュの選定ガイド

Last updated at 2026-03-03Posted at 2026-03-02

Cilium vs Istio Ambient：2026年サイドカーレスサービスメッシュの選定ガイド

この記事でわかること

サイドカーレスサービスメッシュの二大選択肢であるCiliumとIstio Ambientのアーキテクチャの違い
ベンチマーク論文に基づくP99レイテンシ・CPU・メモリ消費量の定量比較
L4/L7処理の分離設計の違いとそれぞれのトレードオフ
Cilium 1.19のZtunnel統合によるIstioとの相互運用の仕組みと制約
ユースケース別の選定基準と、両者を組み合わせた防御多層化戦略

対象読者

想定読者: Kubernetesでサービスメッシュの導入・移行を検討している中級者のインフラエンジニア・SRE
必要な前提知識:
- Kubernetes 1.28以降の基本操作（kubectl、Helm）
- サービスメッシュの概念（サイドカープロキシ、mTLS、トラフィック管理）の基本理解
- Linuxネットワーキングの基礎（TCP/IP、iptables）

関連記事: Cilium単体の導入手順やHubbleの設定方法については、CiliumとeBPFでサイドカーレスメッシュを構築しネットワーク遅延を削減する実践ガイドで詳しく解説しています。本記事ではCiliumとIstio Ambientの比較・選定に焦点を当てます。

結論・成果

2026年3月時点で、サイドカーレスサービスメッシュの選択肢はCiliumとIstio Ambientに集約されつつあります。ベンチマーク論文（arxiv）の計測データによると、CiliumはCPU消費量が+0.12 coresで全フレームワーク中最小である一方、Istio AmbientはmTLS有効時のP99レイテンシ増加率が+8%で最小です。つまり、L4トラフィックが中心でCPU効率を重視するならCilium、mTLS暗号化のオーバーヘッド最小化とL7機能の柔軟性を重視するならIstio Ambientが有利です。

ただし、どちらかが一方的に優れているわけではありません。実際の本番環境では、CiliumをL3/L4のCNIとして使いつつ、IstioをL7ポリシーとmTLSの暗号化に使う防御多層化（defense-in-depth）戦略も採用されています。本記事では、ベンチマークデータと設計思想の違いを整理し、読者のワークロードに合った選定判断を支援します。

サイドカーレスの二大アーキテクチャを理解する

サイドカーレスサービスメッシュは「Podごとにプロキシを配置しない」という共通の目標を持ちますが、CiliumとIstio Ambientでは達成手段が大きく異なります。ここでは、それぞれのデータパスと設計思想を整理します。

Ciliumのアーキテクチャ：eBPFによるカーネル内処理

CiliumはeBPF（extended Berkeley Packet Filter）を活用し、L3/L4のネットワーク処理をLinuxカーネル内で完結させるアプローチを採用しています。Cilium公式ドキュメントによると、eBPFプログラムはXDP（eXpress Data Path）、TC（Traffic Control）、Socketの各フックポイントにアタッチされ、パケット処理を行います。

設計思想のポイント:

L4まではカーネル完結: ユーザー空間へのコンテキストスイッチが不要で、サイドカーによるhop追加がない
L7はオプション: L7プロトコル解析（HTTP、gRPC、Kafka等）が必要な場合のみ、ノード単位のEnvoyプロキシにトラフィックをリダイレクトする（公式ドキュメント）
CNI統合: CiliumはKubernetesのCNI（Container Network Interface）として動作し、kube-proxyを置換できる

よくある間違い: 「CiliumはEnvoyを使わない」と誤解されがちですが、L7ポリシーが必要な場合にはノード単位のEnvoyプロキシが使用されます。違いは「Pod単位」ではなく「ノード単位」である点です。100 Podsが稼働するノードでもEnvoyインスタンスは1つで済みます。

Istio Ambientのアーキテクチャ：Ztunnel + Waypoint の2層構造

Istio AmbientはL4とL7を明確に分離した2層アーキテクチャを採用しています。Istio公式ドキュメントによると、L4セキュリティはZtunnel（Zero Trust Tunnel）が担い、L7ポリシーはWaypoint Proxyが担います。

設計思想のポイント:

L4はノード常駐: Ztunnelは各ノードにDaemonSetとしてデプロイされ、Pod間通信のmTLS暗号化・認証をデフォルトで有効化する。Rustで実装されており、L4処理に特化した軽量プロキシである（Ztunnel GitHub）
L7はオンデマンド: Waypoint ProxyはNamespace単位またはService Account単位でデプロイされ、HTTPルーティング、レート制限、サーキットブレーカー等のL7機能を提供する。不要なNamespaceにはデプロイしない
HBONE プロトコル: Ztunnel間の通信はHBONE（HTTP-Based Overlay Network Environment）というHTTP/2ベースのトンネリングプロトコルで暗号化される（Istio Traffic Redirection）

制約条件: Waypoint ProxyはL7ポリシーが必要なNamespaceにのみデプロイされますが、「L7ポリシーが必要かどうか」の判断は運用者に委ねられています。L4のみで十分なユースケースではWaypointを省略でき、リソース消費をさらに抑えられます。ただし、Waypoint Proxyはアプリケーションと同一ノードに配置されるとは限らず、ノード間通信が発生する場合があります。

設計思想の根本的な違いを整理する

両者のアーキテクチャを比較すると、根本的な設計哲学の違いが見えてきます。

観点	Cilium	Istio Ambient
L4処理の場所	カーネル内（eBPF）	ユーザー空間（Ztunnel）
L7処理の場所	ノード単位Envoy	Namespace/SA単位Waypoint
コントロールプレーン	ノード分散型（各ノードにエージェント）	中央集権型（Istiod）
暗号化方式	WireGuard / IPsec / Ztunnel（Beta）	FIPS準拠mTLS（デフォルト有効）
ノード内通信の暗号化	デフォルト無効（設計上の選択）	デフォルト有効（mTLS）
CNI機能	CNIとして動作（kube-proxy置換可）	別途CNI必須（Ciliumと組み合わせ可）
カーネル要件	Linux 5.4+（推奨5.8+）	特になし
FIPS準拠	WireGuardは非FIPS	mTLS標準でFIPS準拠

トレードオフの整理: Ciliumはカーネルレベルの処理でCPU効率に優れますが、暗号化方式がFIPS非準拠（WireGuard）であり、規制産業での採用にはIPsecまたはZtunnel統合が必要です。Istio AmbientはデフォルトでmTLSを提供しFIPS準拠ですが、ユーザー空間での処理であるためCPU効率ではCiliumに劣ります。

ベンチマーク論文で性能を比較する

設計の違いが実際の性能にどう影響するのか、公開されているベンチマーク結果をもとに定量比較します。

mTLS有効時のレイテンシとリソース消費を比較する

arxivに公開されている論文「Performance Comparison of Service Mesh Frameworks: the MTLS Test Case」（arxiv）では、mTLSを有効にした状態での各サービスメッシュの性能が比較されています。テスト条件は3,200 RPS、ノード内通信です。

P99レイテンシ増加率（mTLS有効、3,200 RPS）:

フレームワーク	アーキテクチャ	P99レイテンシ増加	増加率
Istio Ambient	サイドカーレス（Ztunnel）	+0.02s	+8%
Linkerd	サイドカー	+0.09s	+33%
Cilium	サイドカーレス（eBPF）	+0.22s	+99%
Istio（サイドカー）	サイドカー	+0.38s	+166%

CPU消費量の増加（クライアント側、3,200 RPS）:

フレームワーク	CPU増加	メモリ増加
Cilium	+0.12 cores	+95 MiB
Istio Ambient	+0.23 cores	+26 MiB
Linkerd	+0.29 cores	+62 MiB
Istio（サイドカー）	+0.81 cores	+255 MiB

この論文のベンチマークから読み取れる重要なポイントを整理します。

CiliumのCPU効率: CPU消費量が+0.12 coresで全フレームワーク中最小です。eBPFがカーネル内で処理を完結するため、ユーザー空間でのプロキシ処理にCPUリソースを消費しません。L4トラフィックが大半を占めるストリーミングやゲームサーバーのようなワークロードでは、この差が顕著になります。

Istio Ambientのレイテンシ効率: mTLS有効時のP99レイテンシ増加率が+8%で全フレームワーク中最小です。ZtunnelがRust製の軽量プロキシであり、mTLS処理に最適化されていることがこの結果に寄与していると考えられます。

CiliumのmTLSオーバーヘッド: 論文の著者らは、Ciliumがノード内通信のネットワーク暗号化をデフォルトで無効にしている設計上の選択がこの結果に影響していると指摘しています。Ciliumは暗号化なしでの高速処理に最適化されており、暗号化を強制するとオーバーヘッドが顕著になります。

注意: このベンチマークは論文公開時点（2024年11月）のバージョンで実施されたものです。Cilium 1.19（2026年2月リリース）ではZtunnel統合やWireGuard厳格モードが導入されており、暗号化性能が改善されている可能性があります。

高負荷時の挙動の違いを理解する

同論文では12,800 RPSの高負荷テストも実施されています。この条件下では、フレームワーク間の差がさらに明確になります。

論文のベンチマークによると、Istio（サイドカーモード）は12,800 RPSのターゲットを達成できず、6,868 RPSにとどまりました。一方、Cilium、Istio Ambient、Linkerdはターゲットを達成しています。

HTTP解析のコスト: 論文ではIstioの設定を段階的に無効化する実験も行われており、mTLSやメトリクス収集よりもHTTP解析（L7パース）が最大のボトルネックであることが明らかになっています。TCPモード（L4のみ）に切り替えると、スループットが約5倍に改善されたと報告されています。

この知見は選定判断に直結します。L7解析が不要なワークロードでは、L4に特化したCiliumやIstio AmbientのZtunnelのみの構成が圧倒的に有利です。

大規模クラスタでのスケーラビリティを比較する

Istio公式ブログの比較記事では、500サービス・50,000 Pod・1,000ノードの大規模クラスタでの検証結果が報告されています。

Istio側の主張によると:

スループット: IstioがCiliumと比較して「56%多くのクエリを20%低いテイルレイテンシで処理」
効率性: Istioは1コアあたり2,178クエリ、Ciliumは1,815クエリ
Ciliumのコントロールプレーン課題: 各ノードにコントロールプレーンインスタンスが配置される分散型アーキテクチャのため、大規模クラスタでAPIサーバーへの負荷が増大し、不安定になるケースがあったと報告されている

この結果の解釈に関する注意: 上記のベンチマークはIstioプロジェクト側が公開したものであり、テスト条件や測定方法の詳細は検証が必要です。Cilium側からの反論や独立したベンチマークも含めて総合的に判断することを推奨します。

ハマりポイント: Ciliumの分散型コントロールプレーン（各ノードにCiliumエージェント）は、小〜中規模クラスタでは運用が簡単ですが、1,000ノード超の大規模環境ではAPIサーバーへのwatch負荷が問題になることがあります。Istioの中央集権型コントロールプレーン（Istiod）は、大規模環境でのスケーラビリティに設計上の優位性があります。

Cilium 1.19のZtunnel統合を理解する

2026年2月にリリースされたCilium 1.19（InfoQ）では、Istio AmbientのコンポーネントであるZtunnelをCiliumに統合する機能がBetaとして追加されました。この動きはサービスメッシュの選定判断に大きな影響を与えます。

Ztunnel統合の仕組みと設定方法

Cilium公式ドキュメントによると、Ztunnel統合を有効にすると、CiliumエージェントがZtunnelプロキシと連携し、Pod間通信の透過的なmTLS暗号化を実現します。

# Cilium 1.19でZtunnel統合を有効化する
cilium install --version 1.19.1 \
  --set encryption.enabled=true \
  --set encryption.type=ztunnel

# Namespaceを登録してmTLSを有効化
kubectl label namespace production io.cilium/mtls-enabled=true

# 登録状態を確認
kubectl get namespaces -l io.cilium/mtls-enabled=true

Ztunnel統合が意味すること: CiliumのL3/L4処理はeBPFがカーネル内で行い、mTLS暗号化はZtunnelが担当するハイブリッド構成が実現します。これにより、CiliumのCPU効率の高さとZtunnelのmTLS最適化を組み合わせることが可能です。

Ztunnel統合の現在の制約

ただし、Ztunnel統合は2026年3月時点でBetaステータスであり、以下の制約があります。

制約	詳細
登録粒度	Namespace単位のみ（Pod単位は未サポート）
対応プロトコル	TCPのみ（UDPは非対応）
Cluster Mesh非互換	Ztunnel有効時はCluster Meshを同時に使用できない
HostNetwork非対応	HostNetworkを使用するPodは登録不可
NetworkPolicyとの競合	暗号化トラフィックにはNetworkPolicyが適用されない（HBONEポート15008のみ対象）

# Ztunnel統合の動作確認
# 1. 暗号化が有効か確認
kubectl -n kube-system describe cm cilium-config | grep enable-ztunnel

# 2. tcpdumpでHBONEトラフィック（ポート15008）を確認
kubectl exec -n kube-system ds/cilium -- \
  tcpdump -i any port 15008 -c 5

# 3. Ztunnelの登録状態をStateDBで確認
kubectl exec -n kube-system ds/cilium -- \
  cilium-dbg statedb dump | jq '."mtls-enrolled-namespaces"'

トレードオフ: Ztunnel統合を使えばCilium環境でmTLSを有効化できますが、Cluster Meshとの非互換性は大きな制約です。マルチクラスタ構成が必要な場合は、WireGuardまたはIPsecを暗号化手段として選択するか、Istio Ambientを直接採用する方が現時点では適切です。

Cilium 1.19のその他の注目機能

Ztunnel統合以外にも、Cilium 1.19には選定判断に影響する機能が追加されています（Isovalent公式ブログ）。

WireGuard + eBPF Host Routingの両立: 以前は非互換だったIPsec暗号化と高性能なeBPFホストルーティングが同時に使用可能に
Multi Pool IPAM Stable昇格: 複数のIPアドレスプールを使い分けるIPAMが安定版に
Gateway API v1.4サポート: GRPCRouteによるネイティブgRPCトラフィックルーティングに対応
IPv6 L2 Announcements: Neighbor Discoveryを使ったIPv6のL2アナウンスをサポート

ユースケース別の選定基準を整理する

ここまでの分析をもとに、ワークロード特性ごとの選定基準を整理します。

選定フローチャート

ユースケース別の推奨構成

ユースケース	推奨	理由
ストリーミング・ゲームサーバー（L4中心）	Cilium	eBPFのL4処理でCPU消費が最小（+0.12 cores）
金融・医療（FIPS準拠必須）	Istio Ambient	FIPS準拠mTLSがデフォルト有効
マイクロサービス（HTTP API中心、L7必要）	Istio Ambient	Waypoint Proxyの柔軟なL7ポリシー
大規模クラスタ（1000ノード超）	Istio Ambient	中央集権型コントロールプレーンのスケーラビリティ
コスト重視の中規模環境	Cilium	リソースオーバーヘッドが最小
防御多層化	Cilium（CNI） + Istio（L7/mTLS）	L3/L4はeBPF、L7/暗号化はIstioで分担

防御多層化戦略：CiliumとIstioを組み合わせる

CiliumとIstio Ambientは排他的な選択肢ではありません。Tetrate社のブログによると、多くの企業がCiliumのL3/L4機能とIstioのL4/L7暗号化機能を組み合わせた防御多層化戦略を採用しています。

# 構成例: Cilium CNI + Istio Ambient
# 1. CiliumをCNIとしてインストール（kube-proxy置換）
# cilium install --set kubeProxyReplacement=true

# 2. Istio AmbientをCilium上にインストール
# istioctl install --set profile=ambient

# 3. Namespace単位でAmbientメッシュに登録
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    istio.io/dataplane-mode: ambient  # Istio Ambient有効化
---
# 4. L7ポリシーが必要なNamespaceにWaypointをデプロイ
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: production-waypoint
  namespace: production
  labels:
    istio.io/waypoint-for: service
spec:
  gatewayClassName: istio-waypoint
  listeners:
    - name: mesh
      port: 15008
      protocol: HBONE

この構成の利点:

CiliumのeBPFがL3/L4のネットワークポリシーとロードバランシングを高速に処理
IstioのZtunnelがPod間通信のmTLS暗号化を透過的に実施
L7ポリシーが必要な箇所のみWaypoint Proxyをデプロイし、リソース消費を最小化

制約条件: この組み合わせ構成では、CiliumのZtunnel統合（encryption.type=ztunnel）は使用しません。Istio側のZtunnelとCilium側のZtunnel統合は別物であり、両方を同時に有効にすると競合する可能性があります。Cilium側のZtunnel統合は、Istioを使わずにCilium単体でmTLSを実現したい場合に使用します。

よくある問題と解決方法

サービスメッシュの選定・導入時に遭遇しやすい問題を整理します。

問題	原因	解決方法
CiliumでmTLS有効化後にレイテンシが大幅に増加	デフォルトでノード内暗号化が無効のため、有効化時のオーバーヘッドが大きい	WireGuardの段階的有効化、またはZtunnel統合（Beta）の検討
Istio Ambientで一部PodのL7メトリクスが取得できない	Waypoint ProxyがデプロイされていないNamespace	`istioctl waypoint apply`でWaypointをデプロイ
Ciliumの大規模クラスタでAPIサーバー負荷が増大	ノード分散型コントロールプレーンのwatch負荷	Cilium Operator設定の最適化、APIサーバーのスケールアウト
CiliumとIstioの組み合わせでNetworkPolicyが期待通り動作しない	CiliumNetworkPolicyとIstio AuthorizationPolicyの競合	L3/L4はCiliumNetworkPolicy、L7はIstio AuthorizationPolicyで明確に分担
Cilium Ztunnel統合でCluster Meshが使えない	現時点での制約（Beta）	マルチクラスタが必要な場合はWireGuardまたはIstio Ambientを使用
Istio AmbientのWaypoint Proxyが別ノードに配置される	Waypoint Proxyはスケジューラに委ねられる	nodeAffinityやtopologySpreadConstraintsで配置を制御

# トラブルシューティングコマンド集

# Cilium: eBPFプログラムのロード状態を確認
kubectl exec -n kube-system ds/cilium -- cilium bpf prog list

# Cilium: 暗号化ステータスの確認
kubectl exec -n kube-system ds/cilium -- cilium encrypt status

# Istio Ambient: Ztunnelの状態確認
kubectl -n istio-system logs ds/ztunnel --tail=50

# Istio Ambient: Waypoint Proxyの一覧
kubectl get gateways -A -l istio.io/waypoint-for

# Istio Ambient: メッシュに登録されているNamespaceの確認
kubectl get namespaces -l istio.io/dataplane-mode=ambient

まとめと次のステップ

まとめ:

CiliumはeBPFによるカーネル内処理でCPU消費量が最小（+0.12 cores）だが、mTLS有効時のレイテンシ増加率は+99%と大きい
Istio AmbientはZtunnel + Waypointの2層構造でmTLSレイテンシ増加率が+8%と最小であり、メモリ消費量も+26 MiBで効率的
両者は排他的ではなく、CiliumをCNI（L3/L4）、Istio AmbientをL7/mTLSに使う防御多層化戦略が実践されている
Cilium 1.19のZtunnel統合（Beta）により、Cilium単体でもmTLSが可能になったが、Cluster Mesh非互換などの制約がある
L4中心・CPU効率重視ならCilium、mTLS必須・L7ポリシー重視・FIPS準拠が必要ならIstio Ambientが適している

次にやるべきこと:

テスト環境で両方のフレームワークを導入し、自社ワークロードでのレイテンシ・CPU・メモリを計測する
FIPS準拠、マルチクラスタ、L7ポリシーの要否など、自社の非機能要件を明確化して選定基準を確定する
防御多層化戦略を採用する場合は、CiliumNetworkPolicyとIstio AuthorizationPolicyの責務分担を設計する

参考

注意: この記事はAI（Claude Code）により自動生成されました。内容の正確性については複数の情報源で検証していますが、実際の利用時は公式ドキュメントもご確認ください。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up