サイドカーを排除：Ambient Networkingによるサイドカー不要なサービスメッシュへの移行

EnvoyサイドカーをすべてのKubernetesポッド内に配置するのは、クラウドコストの大きな無駄です。Ambient networkingはLayer 4とLayer 7の処理をノードレベルで分離し、サイドカーのオーバーヘッドを排除しつつ、ゼロトラストの暗号化を維持します。以下は、現在のベンチマークとIstioリリース履歴（1.30まで）に基づく全体的なアーキテクチャの概要です。

---

サイドカー税：従来モデルがクラウド予算を圧迫する理由

クラウドネイティブアーキテクチャの進化は、デカップリングによって定義されてきました。アプリケーションと物理サーバーの分離、ランタイム依存関係とコンテナ、ネットワークロジックとアプリコードの分離です。長年、最後のデカップリングの業界標準はサイドカー・プロキシモデルであり、最も有名なのはIstioです。

このモデルは、Envoyプロキシコンテナを各アプリケーションポッドに注入します。プロキシはすべてのインバウンド・アウトバウンドトラフィックを捕捉し、相互TLS（mTLS）暗号化、テレメトリ生成、トラフィックルーティング、認可ポリシーを処理します。抽象化はシンプルですが、そのコストはそうではありません。

Kubernetesの展開が数十から数千のマイクロサービスに拡大するにつれ、サイドカー・モデルの根本的な欠陥が無視できなくなってきました。それは、クラスター内の各ポッドに対して完全なEnvoyプロセスを実行していることです。この税負担は以下の3つの側面に及びます。

1. リソースの肥大化とクラウドコスト

Envoyは高性能なプロキシですが、専用のCPUとメモリが必要です。Kubernetesでは、各コンテナがリソースリクエストとリミットを宣言しなければなりません。1,000ポッドの場合、1,000のEnvoyプロキシライフサイクルを管理します。

トラフィックのスパイクは予測できないため、プラットフォームチームは最悪の負荷に備えてサイドカーをプロビジョニングします。ピークトラフィックに対応するために0.2 vCPUと64MB RAMを必要とするサイドカーは、2,500ポッドのクラスターではネットワークのためだけに500 vCPUと160GBのメモリを予約します。多くのエンタープライズ環境では、サービスメッシュのデータプレーンがビジネスロジックよりも多くの計算資源を消費しています。

2. ライフサイクル管理の運用上の悪夢

サイドカーはアプリケーションと同じポッドに共存しているため、ライフサイクルが連動します。EnvoyのCVEパッチやメッシュバージョンのアップグレードには、すべてのアプリケーションポッドのローリング再起動が必要です。これは基本的なインフラの原則に反します：ネットワークの変更はアプリケーションの再起動を引き起こすべきではありません。

この連動は、ポッドの起動時にレースコンディションも引き起こします。アプリケーションコンテナがサイドカーのルーティング準備前に初期化されると、リクエストが失敗し、クラッシュループやCI/CDパイプラインの停止を招きます。Kubernetesのジョブは特に問題で、インジェクトされたサイドカーが終了しない場合、ジョブのポッドが無期限に孤立します。

3. “全てか無か”の計算ペナルティ

従来のサイドカーはLayer 4（L4）のトランスポートセキュリティとLayer 7（L7）のアプリケーションルーティングを混同しています。マイクロサービスがmTLS暗号化だけを必要とし、HTTPリトライやヘッダー操作、トラフィック分割を必要としなくても、サイドカーを通過するすべてのパケットは完全なL7 HTTP解析のコストを支払います。オプトアウトの方法はありません。

---

Ambient Networkingデータプレーンの登場

これらの問題に対するアーキテクチャ的な解決策は、Istio Ambient Modeです。2022年9月に発表され、2024年11月7日にIstio 1.24で正式リリースされました。GAでは、ztunnel、waypoints、および関連APIがIstio Technical Oversight CommitteeによってStableとマークされ、完全な本番運用の準備が整いました。Docker Hubのztunnelイメージは、その時点で1百万回以上のダウンロードを記録し、リリース前の最終週には約63,000回のプルがありました。

Ambient networkingデータプレーンの核となるアイデアは、関心の分離です。基本的なセキュリティ（L4）はインフラの不可視の特性として存在し、高度なアプリケーションネットワーキング（L7）はオプトイン方式で適用されます。そのためには、アプリケーションポッドからプロキシを完全に排除し、2つの新しいコンポーネントに置き換えます：Ztunnel（L4用）とWaypoint Proxy（L7用）です。

---

Ztunnel：Layer 4カーネルトランスポートセキュリティのマスター

Ztunnel（Zero Trust Tunnel）は、サイドカー不要なサービスメッシュの基盤です。Rustで書かれた、目的特化型のノードレベルプロキシで、メモリ安全性、速度、超低リソースフットプリントを重視しています。

ZtunnelはKubernetesのDaemonSetとして展開されます。各ノードに1つずつ配置され、そのノード上のポッド数に関係なく動作します。公式のIstioパフォーマンスドキュメントによると、1,000リクエスト/秒の負荷下での単一のztunnelプロキシは、約0.06 vCPUと12MBのメモリを消費します。このアイドル/低負荷時のプロファイルは意味のある制約です。高密度のポッド環境では、ノード上のすべてのポッドに対して統計的多重化の恩恵を受け、実際のメモリ使用量は構成状態に応じて通常30〜50MBの範囲に収まります。

ZtunnelはOSIのLayer 3と4に厳密に対応します。HTTPリクエストの解析やJSONペイロードの読み取り、トラフィック分割は行いません。責務は以下の通りです：

• ポッドのためのmTLS接続の確立と終了
• Layer 4のネットワーク認可ポリシーの施行（例：「サービスAはポート8080でサービスBに到達可能」）
• TCPの基本的なテレメトリ指標の出力

Ztunnelにサイドカーなしでトラフィックが到達する仕組み

この透過的なインターセプションを可能にする仕組みは、1.xリリースサイクルを通じて進化してきました。現在のIstioリリースのデフォルトモードはインポッドリダイレクションです。Istio CNIノードエージェントは、ポッドのネットワーク名前空間をztunnelに提供し、その名前空間内にリダイレクションソケットを起動します。一方、ztunnelはポッドの外側で動作します。トラフィックのリダイレクションは、Kubernetesの主要なCNI（Cilium、Calico、Flannel、OpenShiftやAmazon EKSの内製CNIなど）と競合せずに動作します。

以前の仕組みは、iptablesルールとGENEVEオーバーレイトンネルを組み合わせて使用していました。これは、ノードのネットワーク名前空間でトラフィックをマークしリダイレクトする必要があり、多くのサードパーティCNIと競合しました。現在のインポッドアプローチは、普遍的なCNI互換性を実現するために導入され、基本的な移植性の制約を解決しています。

また、`redirectMode: