Istio Ambient Mesh とは何か(sidecar モデルとの違い)

[hiramekun]

[claude]

Claude finished @hiramekun's task in 1m 37s —— View job

---

概要

Istio Ambient Mesh は、従来の sidecar モデル（各 Pod に Envoy プロキシを 1 つずつ注入する方式）に代わる、サイドカーを使わないデータプレーンです。Istio 1.24（2024年11月）で GA（正式版）となりました。ノードごとに 1 つ動く ztunnel という軽量プロキシが L4 レベルのセキュア通信（mTLS・認証）を担当し、HTTP ルーティングや L7 の認可などリッチな機能が必要な場合だけ、名前空間・サービス単位で waypoint プロキシをオプションで追加する、という 2 層構成になっています。

flowchart TB
    subgraph "sidecar モデル"
        direction TB
        subgraph PodA1["Pod: frontend"]
            AppA1["アプリ"] --- EnvoyA1["Envoy sidecar"]
        end
        subgraph PodB1["Pod: backend"]
            AppB1["アプリ"] --- EnvoyB1["Envoy sidecar"]
        end
        EnvoyA1 <-->|"mTLS / L4 / L7 すべて"| EnvoyB1
    end

    subgraph "ambient モデル"
        direction TB
        subgraph Node1["ノード1"]
            AppA2["アプリ (frontend)"]
            Ztunnel1["ztunnel (ノードごとに1つ)"]
        end
        subgraph Node2["ノード2"]
            AppB2["アプリ (backend)"]
            Ztunnel2["ztunnel (ノードごとに1つ)"]
        end
        Waypoint["waypoint proxy<br/>(L7が必要な場合のみ)"]
        AppA2 --- Ztunnel1
        AppB2 --- Ztunnel2
        Ztunnel1 <-->|"HBONE でmTLS化されたL4トンネル"| Ztunnel2
        Ztunnel2 -.->|"L7ルーティング/認可が必要なときだけ経由"| Waypoint
    end

Loading

何が嬉しいのか

sidecar モデルでは、通信を行うすべての Pod に Envoy コンテナを 1 つずつ注入するため、Pod 数に比例してメモリ・CPU のオーバーヘッドが増え、Pod の起動順序（sidecar が先に起動していないとアプリの通信が失敗する "hold application start" 問題）や、Envoy の設定変更のたびに全 Pod への再配布・再起動リスクなど、運用上のコストが積み上がっていました。また、既存のアプリケーションに mesh を有効化するには Pod の再作成（sidecar 注入）が必要で、段階的な導入がしにくいという課題もありました。

Ambient Mesh はこれを解決します。

• リソース効率: プロキシがノードあたり1つ（ztunnel）で済むため、Pod 数が多い環境でもメモリ・CPU 消費が大幅に減る。特に大規模クラスタや、Pod が頻繁にスケールするワークロードで効果が大きい
• 段階的な導入のしやすさ: Pod の再起動なしに namespace 単位で mesh へ追加・除外ができる（ztunnel によるトラフィックキャプチャは iptables/eBPF ベースでノード側から行われるため）。「まず mTLS だけ有効化して、必要なサービスだけ waypoint で L7 機能を足す」という段階的な適用がしやすい
• アップグレードの独立性: L4 (ztunnel) と L7 (waypoint) のライフサイクルが分離されているため、L7 機能を使わないシンプルな通信ではアップグレード対象が減り、ダウンタイムのリスクも下がる

典型的なユースケースとしては、「数千 Pod 規模のクラスタで mTLS によるゼロトラストは全体に効かせたいが、L7 のトラフィック制御は一部の重要なサービスにしか使わない」「Pod あたりのリソースが厳しい環境（AI/ML の GPU ワークロードなど）で sidecar のオーバーヘッドを避けたい」といった場面が挙げられます。

詳細

コンポーネント

• ztunnel（zero-trust tunnel）: 各ノードに DaemonSet として 1 つデプロイされる Rust 製の軽量プロキシ。ノード上の全 Pod の代わりにトラフィックを透過的にキャプチャし、HBONE（HTTP-Based Overlay Network Environment、実体は mTLS 上の HTTP/2 トンネル）でノード間通信を暗号化・認証する。L4 レベルの機能（mTLS、L4 認可ポリシー）のみを扱い、HTTP ヘッダなどのアプリケーション層は解釈しない
• waypoint プロキシ: namespace やサービスアカウント単位でオプトインするデプロイ。中身は sidecar モデルと同じ Envoy で、HTTP ルーティング・リトライ・タイムアウト・L7 の AuthorizationPolicy（HTTP メソッドやパスに基づく認可）などを担当する。waypoint を有効化していないサービスは ztunnel による L4 の保護のみを受ける

トラフィックの流れ

1. Pod のトラフィックは iptables（または ztunnel の CNI プラグインによる eBPF/ルーティング設定）によって、同ノードの ztunnel に透過的にリダイレクトされる
2. 送信元 ztunnel と宛先ノードの ztunnel の間で HBONE トンネルが確立され、mTLS で暗号化された状態で L4 通信が行われる（#41 で解説した Istio の mTLS の仕組みは ambient モードでも考え方は共通）
3. 宛先の namespace/サービスに waypoint が設定されている場合は、ztunnel から waypoint 経由でルーティングされ、L7 のポリシーが適用されたのちアプリケーションへ届く。waypoint が無い場合は ztunnel から直接アプリケーションへ届く

注意点

• L7 機能（HTTP ベースのルーティングやリトライ、詳細な AuthorizationPolicy など）を使う場合は waypoint の追加設定が必要で、「sidecar より必ずシンプルになる」わけではない。L7 を多用する構成では sidecar とほぼ同等の複雑さになる
• ztunnel はノードの単一障害点になりうるため、ノード上の全 Pod の通信に影響する（sidecar モデルでは Pod 単位の障害に閉じる）
• 比較的新しい機能のため、Istio や CNI・OS のバージョン要件、サポートされる Kubernetes プラットフォームには制約がある（利用前に公式ドキュメントで最新の要件を確認するのが安全）
• Istio の観測性機能（#53 で解説）は ambient モードでも利用できるが、メトリクスの収集ポイントが ztunnel/waypoint に変わる点は把握しておくとよい

参考リンク

• Istio Ambient Mesh Architecture (公式ドキュメント)
• Istio Blog: Fast, Secure, and Simple — Istio's Ambient Mode Reaches General Availability in v1.24
• Istio Blog: Say goodbye to your sidecars — Istio's ambient mode reaches Beta in v1.22

関連ノート

• #40 Istio とは何か(サービスメッシュの仕組みと導入メリット) — sidecar モデルでの Istio の基本アーキテクチャを解説しており、本ノートの ambient モデルとの比較対象

---

• 既存 issue の重複・関連チェック（Istio とは何か(サービスメッシュの仕組みと導入メリット) #40 が関連ノート、相互リンク済み）
• Istio Ambient Mesh と sidecar モデルの違いについて調査
• 回答コメントの作成
• タイトル編集（「Istio Ambient Mesh とは何か(sidecar モデルとの違い)」）
• ラベル付与（infra, type:comparison）
• 関連 issue（Istio とは何か(サービスメッシュの仕組みと導入メリット) #40）への相互リンク