The Death of the Sidecar: Implementing Ztunnels in Istio Ambient Mesh

プロキシサイドカーはあなたのKubernetesの計算リソース予算を圧迫していませんか？Ambient Mesh Ztunnelsを使ったサイドカー不要の未来へ踏み出しましょう。これらはHBONEプロトコルを利用し、ノードレベルで高性能なゼロトラストルーティングを実現します。

クラウドネイティブインフラの急速な進化の中で、サービスメッシュほど運用哲学に劇的な変化をもたらした技術はほとんどありません。長年、業界は「サイドカー」モデル—各Kubernetesポッドに注入される専用のプロキシ—に大きく依存してきました。このパラダイムは、相互TLS（mTLS）、可観測性、詳細なトラフィック制御といった重要な機能をもたらしました。しかし、クラスターの規模拡大とエンタープライズの採用が加速する中で、サイドカーのアーキテクチャの欠点は無視できなくなりました：大量のCPUとメモリを消費し、アプリケーションのライフサイクルを複雑にし、インフラとアプリケーションチームを密接に結びつける不都合な状態を生み出していたのです。

これらの問題に対する答えが到来しています。Istio Ambient Meshは、Istio 1.24の2024年11月に正式リリースされ、ztunnel、waypoints、すべてのAPIがIstio技術監督委員会によってStableとマークされ、今や新しいKubernetesサービスメッシュ展開のデフォルトとなっています。この変革の中心にあるのがZtunnel (Zero Trust Tunnel)—ノードレベルのプロキシであり、Kubernetesのトラフィックを根本的に安全にルーティングし制御します。

このガイドでは、Istio Ambient MeshとZtunnelの仕組み、HBONEプロトコルの詳細、Istio CNIによるトラフィックリダイレクションの仕組み、そして2026年までの今後の展望について解説します。

---

サイドカー時代：なぜ死ななければならなかったのか

Ambient Meshの設計を理解するには、まずそれが置き換えるモデルの痛みを理解する必要があります。従来のサービスメッシュのデータプレーンは、proxy—通常はEnvoy—を各アプリケーションポッド内のセカンダリコンテナとして実行するものでした。

これにより隔離とポッドごとのコンテキストは優れていましたが、そのオーバーヘッドは非常に大きかったです：

計算リソースの肥大化。 各サイドカーは独自のCPUとメモリの割り当てを必要とします。数百または数千のポッドを持つマイクロサービス環境では、これらのアイドル状態のプロキシリソースがすぐに蓄積します。多くの組織は、サービスメッシュインフラが実際のビジネスロジックと同じくらいの計算予算を消費していることに気づきました。

ライフサイクルの結合と運用の摩擦。 サイドカーは物理的にポッドに注入されるため、メッシュのライフサイクルはアプリケーションのライフサイクルに結びついています。プロキシのアップグレードや証明書のローテーションは、通常、アプリケーション全体のローリングリスタートを必要とし、プラットフォームエンジニアとアプリ開発者の調整を強いるものでした。

「最初のパケット」問題。 ポッドの初期化中にレースコンディションが発生し、アプリケーションコンテナがサイドカーが準備完了する前に起動し、最初の接続がドロップしたり、init-containerの複雑なワークアラウンドが必要になったりしました。

Layer 7の負担。 従来のサイドカーはLayer 4（TCP/mTLS）とLayer 7（HTTP/gRPCルーティング）の両方を処理します。多くのアプリケーションはmTLSの基本的なセキュリティだけを必要としますが、それでも全ての接続でL7のパースにかかる計算負荷を負わされていました。

結論は明白でした：スケールに耐えられるサイドカーのモデルは持続不可能です。解決策は、基盤となるインフラ要件（セキュリティとアイデンティティ）とアプリケーション固有の要件（高度なL7トラフィック管理）を分離することでした。

---

Istio Ambient Mesh：アーキテクチャの概要

Istio Ambient Meshは、透明性と非侵襲性の哲学を通じてこれらの痛点に対処します。サイドカーを完全に排除し、サービスメッシュのデータプレーンを2つの独立してスケーラブルな層に分割します：

• セキュアトランスポート層（Layer 4）： Ztunnelが担当し、mTLS、SPIFFEベースのワークロードアイデンティティ、L4認可ポリシー、ネットワークの可観測性を提供します。
• L7トラフィック管理層： 複雑なHTTPルーティング、リトライ、ルートごとのRBAC、JWT検証、レートリミティングが必要な場合にのみ、オプションのWaypoint Proxyが展開されます。

mTLSを共有インフラストラクチャコンポーネントに移すことで、Ambient Meshはプラットフォームチームがアプリケーションポッドを変更せずにクラスター全体のゼロトラストセキュリティを有効にできるようにします。サイクルの登録は単一コマンドです：

kubectl label namespace default istio.io/dataplane-mode=ambient

このラベルは、Istio CNIノードエージェントに対し、そのネームスペース内の全ポッドのリダイレクション設定をトリガーします—ポッドの再起動やミューテーションWebhook、initコンテナは不要です。

---

Ztunnelの解剖：ノードレベルのゼロトラストプロキシ

Ambient Meshの要はZtunnel (Zero Trust Tunnel)です。過去の機能豊富なEnvoyサイドカーとは異なり、ZtunnelはRustで書かれた高性能なLayer 4プロキシです。最初のAmbient Mesh実装はEnvoyを使用していましたが、IstioチームはEnvoyのL7機能セット—ゲートウェイやwaypointsに最適なもの—がZtunnelの役割には過剰であり、EnvoyをZtunnelの特定要件に合わせて調整するのは非現実的だと判断しました。2023年2月に発表されたこのRust実装は、その問題を解決しました。

アーキテクチャと展開

ZtunnelはKubernetesのDaemonSetとして動作し、各ノードに1つずつ展開され、そのノード上のすべてのワークロードと共有されます。ゼロトラストの基礎的な要素に責任を持ちます：

• Mutual TLS (mTLS): 交通をAES-GCMで暗号化し、ハードウェア最適化された暗号化を実現
• SPIFFEアイデンティティ管理: ZtunnelはCAクライアントとして動作し、Istiodから短命のX.509証明書とSPIFFEアイデンティティをリクエスト・管理します。各ワークロードのアイデンティティはspiffe://<trust-domain>/ns/<namespace>/sa/<service-account>の形式です。
• L4認可ポリシー: ワークロードのアイデンティティに基づく「誰が誰と通信できるか」のルールを強制
• L4可観測性: TCPの標準メトリクスやアクセスログをエクスポートし、各コネクションの送信元と宛先のSPIFFEアイデンティティを記録

Ztunnelはまた、IstiodとxDSクライアントとして通信し、L4専用のxDS設定を受信します。これはEnvoyサイドカーやwaypointsに配信される完全なxDS設定とは異なります。

パフォーマンスと効率

Rustで書かれたLayer 4の動作により、リソース使用量は非常に少なくなっています。公式のIstioパフォーマンスベンチマークによると、1,000リクエスト/秒を処理するZtunnelは約0.06 vCPUと12MBのメモリを消費します。アイドル時のZtunnelは30–50MBのメモリを使用し、CPU負荷は最小です。

Ztunnelチームは、四半期ごとのリリースごとに継続的なパフォーマンス改善を行っており、rustls（高性能・安全性重視のTLSライブラリ）への移行、アウトバウンドトラフィックのデータコピー削減、バッファサイズの動的調整、AWS-LC（最新ハードウェア向けの暗号化ライブラリ）への移行を進めています。

これらの改善により、サイドカーと比較して、z-tunnelのみのAmbientモードは本番ベンチマークで約1%のCPUと12MBのメモリを消費します。Waypointsを展開した場合でも、合計CPUはサイドカーの約15%、メモリは約10%に低減します。

1000ポッドのクラスター（100ノード）での比較例：

モデル	プロキシ数	CPUオーバーヘッド	メモリオーバーヘッド
サイドカー（Envoyをポッドごとに）	1,000	約100 vCPU	約128 GB
Ambient L4のみ（Ztunnel DaemonSet）	100	約6–7 vCPU	約1.2–5 GB
Ambient with Waypoints（サービスの20%）	100 + 数個のWaypoints	約15–20 vCPU	約13–15 GB

リソース要求の削減だけでも、L4のみのAmbientはサイドカーの約99%、Waypointsを使った場合は約85%のCPUと90%のメモリ削減に相当します。

遅延については、Istio 1.23の公式ベンチマークによると、2つのztunnelホップ（クライアント側とサーバー側）は、HTTP/1.1トラフィックでmTLSを有効にした状態で、90パーセンタイルで約0.17ms、99パーセンタイルで約0.20msの遅延を追加します。

ワークロードごとのアイデンティティの維持

ノードレベルのプロキシに関する一般的な懸念は、「ポッドごとのアイデンティティを単一の「ノードアイデンティティ」にまとめてしまうのではないか」という点です。Ztunnelはこれを明示的に避けています。ノード上のすべてのポッドと共有されているにもかかわらず、各ワークロードの証明書管理は個別に行います。

ノード1のPod Aがノード2のPod Bと通信する場合:

1. ノード1のZtunnelは、Pod AのService Account用のユニークなX.509証明書をIstiodからリクエストし、Pod AのSPIFFEアイデンティティを提示します。
2. Istiodは、ZtunnelがPod Aの代理として動作する権限を持つことを確認します（Kubernetes RBACを通じて）。
3. mTLSハンドシェイクはPod Aの特定のSPIFFE証明書を使って行われ、宛先ノードのZtunnelはPod BのL4認可ポリシーと照合します。

結果として、厳格な暗号化されたゼロトラストアイデンティティが、ポッドごとのオーバーヘッドなしに実現します。

---

HBONEプロトコル：標準ベースの安全なトンネリング

アプリケーションに複雑さを露出させずに、ノード間で生のTCPトラフィックを安全に運ぶために、Istio Ambient MeshはHBONE (HTTP-Based Overlay Network Environment)を採用しています。これは、3つのオープンスタンダードを組み合わせたIstio固有のトンネリングプロトコルです：

• HTTP CONNECT (RFC 7540) でトンネル接続を確立
• HTTP/2 で複数のアプリケーション接続ストリームを一つの安全なトンネルに多重化し、ストリームレベルのメタデータを運ぶ
• mTLS でトンネルを暗号化し、相互認証

標準的に、ztunnelや他のHBONE対応プロキシはTCPポート15008でリッスンします。運用者にとっては、既存のNetworkPolicyオブジェクトがambientに登録されたポッドのインバウンドポートを制限している場合、ポート15008またはHBONEトラフィックを明示的に許可する例外を追加する必要があります。

なぜ生のmTLSではないのか？

HTTP/2のCONNECTをキャリアとして使うことで、単一のmTLS接続で多くのポッド間通信を多重化でき、スケール時の接続オーバーヘッドを大幅に削減します。HTTP CONNECTリクエストは、宛先ポッドのIPとポートを:authorityヘッダーに含め、送信元ワークロードのSPIFFEアイデンティティはTLSクライアント証明書で伝えられます。

HBONEは相互運用性も高く、サイドカー型EnvoyプロキシもHBONEをサポートしており、これによりAmbientとサイドカーのワークロードが同じクラスター内で段階的に移行可能です。

HBONEパケットフロー

Pod AがプレーンテキストのTCP接続をサービスに送信すると:

1. インターセプト：Istio CNIはPod Aのネットワーク名前空間からのアウトバウンドトラフィックをローカルのZtunnelにリダイレクトします。
2. カプセル化：ローカルのZtunnelはTCPストリームをHTTP/2のCONNECTリクエストにラップし、宛先IPとポートを:authorityに含めます。
3. mTLSハンドシェイク：ローカルのZtunnelは宛先ノードのZtunnelに対してポート15008でmTLS接続を開始し、Pod AのSPIFFE証明書を提示します。
4. デカプセル化：宛先のZtunnelはPod AのアイデンティティをPod BのL4AuthorizationPolicyと照合し、HTTP/2の封筒を解き、元のTCPストリームをPod Bに届けます。

Pod Aから見ると、普通のTCP接続を送信しただけです。ネットワークの観点からは、多重化され暗号化された、アイデンティティ認証済みのHBONEトンネルを通じてトラフィックが流れています。

---

トラフィックリダイレクション：Istio CNI、iptables、GENEVE、eBPF

アプリケーションポッドからノードレベルのZtunnelへトラフィックを無変更で流すことは、大きなエンジニアリング課題です。IstioはこれをIstio CNIノードエージェントによって解決します。これはポッドのライフサイクルイベントを監視し、リダイレクションルールを動的に設定します。

デフォルトの仕組み：iptables + GENEVE

デフォルト設定では、Istio CNIはiptablesルールとGENEVE（Generic Network Virtualization Encapsulation）オーバーレイトンネルを組み合わせて、ポッドのネットワーク名前空間とZtunnelを橋渡しします。Ztunnelポッドはpistioinとpistiooutインターフェースを公開し、これらはノードのistioinとistiooutインターフェースに接続されます。受信したトラフィックは、HBONE用の15008ポートまたはプレーンテキスト用の15006ポートに送られます。アウトバウンドは15001ポートに向かいます。

TPROXY（Linuxの透過プロキシ）は、トンネルからの受信パケットにマークを付け、z-tunnelのインバウンド・アウトバウンドポートにルーティングします。これにより、上流のポリシー enforcementは実際のワークロードのアドレスを認識します。

eBPFの代替

Istioは、eBPFベースのトラフィックリダイレクションモードも追加しています。これを有効にすると、eBPFプログラムがIstio CNIコンポーネントにコンパイルされ、トラフィック制御（TC） ingress/egressフックにアタッチされます。これにより、ポッドのイベントに応じてeBPFプログラムをアタッチ・デタッチし、iptablesのオーバーヘッドを回避し、GNEVEのカプセル化も不要になります。Ztunnelは、eBPFのマップ内で接続をルックアップし、適切なリダイレクトを行います。

eBPFの利点:

• カーネルレベルの効率性：カーネルとユーザースペース間のコンテキストスイッチを回避
• GNEVEオーバーヘッドなし：パケットはカーネル内で直接リダイレクト
• 柔軟なプログラマビリティ：eBPFプログラムはカーネルモジュールの再ロードなしで更新可能、追加のパケットコンテキストも利用可能
• アプリケーション透過：ポッドはリダイレクトを認識しません

このeBPFモードは、CNIの互換性要件により、Ambientモードのオプションとして現在は選択的に有効化されます。デフォルトのiptables + GENEVEは、Cilium、Calico、OpenShift SDN、Amazon VPC CNIなど、すべてのKubernetes CNIプラグインでサポートされています。

---

Layer 7の分離：Waypoints Proxy

ZtunnelがLayer 4のセキュリティを担当する一方で、HTTPヘッダーに基づくルーティング、トラフィック分割、サーキットブレーカー、ルートごとのRBAC、JWT検証、詳細な分散トレーシングなどの高度なLayer 7機能はどうなるのでしょうか？

Ambient Meshはこれらの課題を処理するためにWaypoint Proxyを導入しています。Waypointは、名前空間、サービス、またはサービスアカウントごとに独立して展開される標準のEnvoyインスタンスです。サイドカーではなく、独立したネットワークインフラとして動作します。Waypointはwaypoint-saというSPIFFEアイデンティティを持ち、Kubernetes Gateway APIリソースを使って展開されます。これにより、アプリケーション展開のパッチではなく、第一級のネットワークインフラとなります。

アーキテクチャは厳密にオプトインです。Ztunnelは、宛先にWaypoint Proxyが設定されていることを自動検知し、トラフィックをHBONEトンネル経由で送信し、その後に宛先に届けます。L4のAuthorizationPolicyは引き続きZtunnel層で適用され、L7のAuthorizationPolicyはWaypointで適用されます。

実用的な展開例：サービスの80%をZtunnelだけ（mTLS、SPIFFEアイデンティティ、L4ポリシー）でルーティングし、HTTPヘッダーのルーティングやカナリアトラフィック分割、詳細なL7 RBACが必要な20%のサービスにのみWaypointを展開します。この選択的展開により、トラフィックに対する「Layer 7の負荷」が排除されます。

注意点：Waypointは、ポッドの元のソースワークロードアイデンティティを使ってポリシーを適用します（Waypoint自身のアイデンティティではありません）。ただし、サイドカーのEnvoyのカスタマイズに広く使われているEnvoyFilter APIはAmbientモードではサポートされていません。拡張はWebAssemblyプラグインを使う必要があります。

---

Ambient Meshの今後：2025–2026年のロードマップ

Istioプロジェクトは、2025–2026年の明確なロードマップを公開しています。主なテーマは以下の通りです：

サイドカーからAmbientへの移行のパリティ。 移行準備状況を評価するツール、同一クラスター内のサイドカーとAmbientネームスペース間の安全な相互運用性、包括的なドキュメントに投資しています。特に、多クラスターのトラフィック管理と拡張性のギャップを埋めることが中心です。

マルチクラスターAmbient Mesh。 2025年8月のIstio 1.27でアルファとしてリリースされたこの機能は、Microsoftの貢献により拡張されました。これにより、複数のクラスター間で安全な接続、サービスディスカバリー、負荷分散が可能となり、エンタープライズの多くから要望のあった機能です。これにより、リージョンやクラウドプロバイダー間のアクティブ-アクティブ構成の土台が築かれます。

Gateway APIと拡張性の成熟。 2026年のKubeCon Europeで、IstioはAmbient Multicluster Beta、Gateway API推論拡張Beta、実験的なAgentgatewayサポートを発表し、サービスメッシュがマイクロサービスネットワーキングを超え、AI推論ワークロード向けのトラフィック管理プラットフォームへと進化していることを示しています。2025年リリースのSail Operatorは、Kubernetesのオペレーターパターンを使ったIstio展開の管理を簡素化します。

---

実践的展開：Ambient Meshの有効化

Ambient Meshへの評価や移行を進めるチームには、段階的なネームスペースごとの採用を推奨します。

Ambientプロファイルのインストール：

istioctl install --set profile=ambient

ネームスペースの登録：

kubectl label namespace my-app istio.io/dataplane-mode=ambient

特定のネームスペースにWaypoints Proxyを展開してL7機能を有効化：

istioctl waypoint apply -n my-app --enroll-namespace

Ztunnelが接続を処理していることを確認（アクセスログのSPIFFEアイデンティティを確認）：

kubectl logs -n istio-system daemonset/ztunnel -f

src.identityとdst.identityのフィールドに、ソースと宛先のSPIFFE URIが記録されていることを確認できます。これは、ワークロードごとのアイデンティティがノードレベルで維持されている証拠です。

必要に応じてロールバック（ポッドの再起動不要）：

kubectl label namespace my-app istio.io/dataplane-mode- --overwrite

---

結論：サイドカーは死んだ、長生きするメッシュ

サービスメッシュは、クラウドネイティブ環境で安全に運用するための基盤的な要件となっています。しかし、サイドカーのアーキテクチャの負債は、多くの組織の採用を妨げてきました。計算オーバーヘッドは実在し、運用の複雑さも深刻でした。ライフサイクルの結合も問題でした。

Istio Ambient Meshは、バージョン1.24以降、これらの問題をアーキテクチャレベルで解決します。L4のセキュリティ（ztunnel、Rust実装で約0.06 vCPUと12MB/ノードで1,000 RPS）とL7のトラフィック管理（waypoints、サービスごとのオプトイン）を分離し、サービスメッシュの本来の約束—堅牢なゼロトラストセキュリティ、深い可観測性、詳細な制御—を、過剰なオーバーヘッドなしに実現しています。

HBONEプロトコルは、HTTP/2、HTTP CONNECT、mTLSを組み合わせ、標準ベースの多重化とアイデンティティ認証を行うトンネルです。これらはアプリケーションからは見えません。Istio CNIは、iptablesとGNEVEによるトラフィックの透過的インターセプションを行います。環境によっては、カーネルレベルの効率と封入オーバーヘッドの低減を目的としたeBPFの高速パスも利用可能です。

2026年のプラットフォームエンジニアリングにとって、選択は明快です：新しいKubernetesサービスメッシュ展開のデフォルトはAmbientモードです。特定の技術的要件を持つワークロードにはサイドカーもサポートされ続けますが、ほとんどのエンタープライズマイクロサービスのトラフィックにおいて、「サイドカー税」の時代は終わりました。

---

チェンジログ

元のドラフトに対し、情報源のウェブ調査に基づき以下の修正と追記を行いました：

正誤 — GAリリースの枠組み： Ambient Meshは2024年11月7日にIstio 1.24で正式リリースされ、ztunnel、waypoints、すべてのAPIがIstio TOCによってStableとマークされました。

正誤 — Ztunnelのメモリベンチマーク： 公式のIstioパフォーマンス資料によると、1,000リクエスト/秒処理のZtunnelは約12MBのメモリを消費します。アイドル時は30–50MBです。15MBの記述は出典不明で不正確でした。

正誤 — eBPFのデフォルト設定： eBPFによるリダイレクトは2026年のAmbient Meshの標準ではなく、iptables + GENEVEがデフォルトです。eBPFはCNIのオプションモードであり、カーネルレベルの効率と封入オーバーヘッドの低減に寄与します。

正誤 — HBONEプロトコルの記述： HBONEはHTTP CONNECT、HTTP/2、mTLSの3つのオープンスタンダードを組み合わせたものです。HTTP/3は含まれません。

正誤 — Ztunnelの起源： ZtunnelはEnvoyを最初に用いて実装され、その後2023年2月にRustに書き換えられました。これにより、性能と効率が向上しています。

追記 — SPIFFEアイデンティティ詳細： Ztunnelは、spiffe://<trust-domain>/ns/<namespace>/sa/<service-account>形式のワークロードごとのSPIFFEアイデンティティをmTLS証明書に含め、Istiodはこれを検証します。

追記 — HBONEポート15008とNetworkPolicyの影響： 既存のNetworkPolicyはポート15008のインバウンドを許可する必要があります。

追記 — Waypointsの制限： EnvoyFilter APIはAmbientモードではサポートされず、拡張にはWebAssemblyプラグインを使います。

追記 — 2025–2026年のロードマップ： マルチクラスターのアルファ版（2025年8月、Istio 1.27）、移行ツール、KubeConでの発表などを含みます。

追記 — 遅延ベンチマーク： Istio 1.23の公式ベンチマークによると、2ホップのztunnelはHTTP/1.1トラフィックでP90約0.17ms、P99約0.20msの遅延を追加します。

追記 — リソース削減の具体例： 99%のCPUとメモリ削減例を引用し、従来のサイドカーと比較しています。