- Published on
Istio Ambient vs Sidecar — 2026年のサービスメッシュアーキテクチャ選定ガイド
- Authors
- Name
- Youngju Kim
- @fjvbn20031
- はじめに
- サイドカーモデルのコスト — 何が問題だったのか
- Ambientアーキテクチャの解剖
- データパス比較 — パケットはどう流れるのか
- 機能パリティの現状 — 2026年時点
- リソース・性能比較 — 計算で確かめる
- 移行戦略 — ネームスペース単位の段階的移行
- インストール実践
- Ciliumとの関係 — 衝突か共存か
- サイドカーが依然として適している場合
- 意思決定ツリー
- トラブルシューティング
- 導入チェックリスト
- おわりに
- 参考資料
はじめに
サービスメッシュを運用したことのあるチームなら、一度はこんな質問を受けたことがあるはずです。「Podが500個あるのに、なぜEnvoyコンテナがさらに500個動いているのですか?」サイドカーモデルはサービスメッシュの標準アーキテクチャでしたが、その代償は決して小さくありませんでした。すべてのPodにプロキシを1つずつ付ける方式は、リソースをほぼ2倍消費し、メッシュのアップグレードのたびに全ワークロードの再起動を強制し、インジェクション設定のミス1つでデプロイ全体を止めてしまいました。
Istio Ambientモードは、この問題に対する構造的な答えです。2024年末のIstio 1.24でGA(General Availability)に到達して以降、2026年現在、Ambientは新規メッシュ構築のデフォルトの選択肢として定着しつつあります。しかし「Ambientが常に正解」という単純な結論は危険です。サイドカーの方が適しているワークロードは明確に存在し、両モードを混在運用する移行期間は、ほとんどの組織で1年以上続くからです。
本記事では、サイドカーモデルのコストを数字で確認し、Ambientアーキテクチャ(ztunnel、waypoint、HBONE)を解剖した上で、両モードのデータパスをパケットフローのレベルで比較します。最後に、ネームスペース単位の段階的移行戦略、意思決定ツリー、トラブルシューティングまで実務の観点で整理します。
サイドカーモデルのコスト — 何が問題だったのか
リソースが2倍かかる
サイドカーモデルでは、すべてのアプリケーションPodにistio-proxy(Envoy)コンテナがインジェクションされます。Envoyサイドカー1つのメモリ使用量は設定規模によって異なりますが、メッシュ全体のサービスディスカバリ情報を保持する必要があるため、クラスタが大きくなるほど一緒に大きくなります。簡単な計算をしてみましょう。
前提:
- クラスタ内のPod数: 500個
- サイドカー1個あたりのメモリ: 平均120MiB (サービス1,000個規模のメッシュ基準)
- サイドカー1個あたりのCPU request: 100m
サイドカーモデルの総オーバーヘッド:
メモリ = 500 x 120MiB = 60,000MiB = 約58.6GiB
CPU request = 500 x 100m = 50 vCPU (requestベースでノードを占有)
ノードのメモリが16GiBの場合:
サイドカーのメモリだけでノード約4台分を消費
CPU request 50 vCPUはスケジューリング可能容量をその分侵食
ここで重要なのは、実際の使用量よりもrequestの予約分です。サイドカーに保守的なrequestを与えるとクラスタのスケジューリング容量が侵食され、小さくしすぎるとトラフィックピーク時にプロキシがOOMKilledされ、アプリケーションまで道連れになります。サイドカーのリソースチューニングは、それ自体が1つの運用業務でした。
アップグレードが苦痛
サイドカーはPodの中に入っているため、プロキシのバージョンを上げるにはPodを再起動する必要があります。つまり、Istioコントロールプレーンを1.25から1.26に上げる作業は、単にistiodを入れ替えるだけでは終わらず、メッシュに属するすべてのワークロードのローリング再起動を伴います。
サイドカーのアップグレード手順 (canary revision方式):
1. istiod 1.26を新しいrevisionタグでインストール (既存1.25と並行稼働)
2. ネームスペースのラベルを新revisionに変更
3. 該当ネームスペースの全Deploymentをrollout restart
4. 全ネームスペースで繰り返し — Pod 5,000個のクラスタなら数時間~数日
5. 旧バージョンのistiodを削除
問題点:
- 再起動が不可能または高コストなワークロード(StatefulSet、バッチ、
セッション維持)が足かせになる
- 再起動漏れのPodは旧バージョンのプロキシのまま残留 → バージョンスキュー発生
- アップグレード周期が四半期1回以上なら、このコストが常時の運用負担になる
インジェクションは思ったより頻繁に壊れる
サイドカーインジェクションはmutating webhookで動作します。ネームスペースのラベル、Podのアノテーション、webhookの設定、revisionタグがすべて揃わなければならず、1つでもずれると「あるPodはメッシュの中、あるPodはメッシュの外」という状態になります。この状態でSTRICT mTLSを有効にすると、インジェクションされていないPodの通信がすべて遮断されます。また、サイドカーのせいでJobが終了しない問題(メインコンテナは完了したのにistio-proxyが生きていてJobがCompletedにならない現象)は、サイドカー時代の代表的な慢性疾患でした。Kubernetesネイティブのサイドカーコンテナ(initContainerのrestartPolicy Always)がこれを緩和しましたが、根本的には「プロキシがPodのライフサイクルに割り込む」という構造自体の問題でした。
Ambientアーキテクチャの解剖
Ambientモードの核心的なアイデアは、プロキシをPodから切り離してインフラレイヤーに下ろすことです。そしてL4とL7を分離し、すべてのワークロードがL7プロキシのコストを強制的に支払わなくて済むようにします。
2つのレイヤー: ztunnelとwaypoint
+----------------------------------------------------------------------+
| Kubernetesクラスタ |
| |
| Node A Node B |
| +------------------------------+ +-----------------------------+ |
| | Pod: app-a Pod: app-b | | Pod: app-c | |
| | (サイドカーなし)(サイドカーなし)| | (サイドカーなし) | |
| | | | | | | | |
| | v v | | v | |
| | +------------------------+ | | +-----------------------+ | |
| | | ztunnel (DaemonSet) |==|====|==| ztunnel (DaemonSet) | | |
| | | L4: mTLS, TCPテレメトリ | | HBONE | L4: mTLS, L4認可 | | |
| | +------------------------+ | | +-----------------------+ | |
| +------------------------------+ +-----------------------------+ |
| |
| L7機能が必要なネームスペースにのみ選択的に: |
| +------------------------------------+ |
| | waypoint proxy (Envoy, Deployment) | |
| | L7: HTTPルーティング、リトライ、 | |
| | L7認可、HTTPテレメトリ | |
| +------------------------------------+ |
| |
| +----------------+ |
| | istiod (制御部) | --- xDS/証明書 ---> ztunnel, waypoint |
| +----------------+ |
+----------------------------------------------------------------------+
- ztunnel(zero-trust tunnel): ノードごとに1つ起動するDaemonSetです。Rustで書かれた軽量プロキシで、Envoyではありません。役割は意図的にL4に限定されています — ワークロード間のmTLS暗号化、SPIFFEアイデンティティに基づくL4認可、TCPレベルのテレメトリ。ztunnelはノード上のすべてのメッシュPodのトラフィックを代わりに暗号化しますが、HTTPをパースしないため、メモリ使用量はPod数ではなくコネクション数に比例する程度に小さく収まります。
- waypoint proxy: L7機能(HTTPヘッダーベースのルーティング、リトライ、タイムアウト、L7 AuthorizationPolicy、HTTPメトリクス)が必要なネームスペースまたはサービスアカウント単位でデプロイするEnvoyベースのプロキシです。Kubernetes Gateway APIのGatewayリソースとして宣言し、通常のDeploymentなのでHPAで独立してスケールできます。
この分離がAmbientの経済性を生み出します。実際の運用でL7ポリシーが必要なサービスは全体の一部です。残りの大多数は「mTLSと基本テレメトリだけで十分」なのに、サイドカーモデルは彼らにもフルEnvoyのコストを課していました。AmbientはL4を標準提供(ztunnel)し、L7は使う分だけ(waypoint)コストを払う構造です。
HBONE — メッシュ内部のトンネルプロトコル
Ambientでは、ノード間トラフィックはHBONE(HTTP-Based Overlay Network Environment)トンネルを流れます。HBONEはHTTP/2 CONNECTメソッドを使い、mTLS接続の上に元のTCPストリームをカプセル化するプロトコルで、ポート15008を使用します。
HBONEトンネル構造 (ポート15008):
+-------------------------------------------------------+
| TCP (Node A ztunnel -> Node B ztunnel, 宛先 :15008) |
| +---------------------------------------------------+|
| | mTLS (SPIFFEアイデンティティの相互検証) ||
| | +-----------------------------------------------+ ||
| | | HTTP/2 | ||
| | | CONNECTリクエスト: 宛先Pod IP:ポートを指定 | ||
| | | +-------------------------------------------+| ||
| | | | 元のアプリケーションTCPバイトストリーム || ||
| | | +-------------------------------------------+| ||
| | +-----------------------------------------------+ ||
| +---------------------------------------------------+|
+-------------------------------------------------------+
HTTP/2のストリーム多重化のおかげで、同じノードペア間の複数のワークロード接続が1つのmTLS接続を共有でき、接続数とハンドシェイクコストが削減されます。また、CONNECTヘッダーに元の宛先とアイデンティティ情報が載るため、受信側のztunnelはペイロードを開かずにL4認可の判断を下せます。
トラフィックリダイレクション — サイドカーと何が違うのか
サイドカーモデルは、Podのネットワークネームスペース内でiptables REDIRECTを使ってトラフィックをistio-proxyに回していました。Ambientでは、istio-cniノードエージェントがPodのネットワークネームスペース内にリダイレクションルールを設置しますが、トラフィックは同じノードのztunnelソケットに転送されます。Podのスペックは一切変更されないため、再起動なしでメッシュへの編入・離脱が可能です。ネームスペースにラベルを1つ付けるだけです。
# ネームスペースをambientメッシュに編入 — Podの再起動不要
kubectl label namespace payments istio.io/dataplane-mode=ambient
# メッシュから除外
kubectl label namespace payments istio.io/dataplane-mode-
データパス比較 — パケットはどう流れるのか
サイドカーモードのリクエストパス
[サイドカーモード] app-a (Node A) -> app-b (Node B) HTTP呼び出し
app-aコンテナ
| (1) localhostアウトバウンド、iptablesが横取り
v
app-a Podのistio-proxy (Envoy) <- L4+L7処理 (ホップ1)
| (2) mTLS暗号化、ルーティング/リトライ/テレメトリ
v
(ノード間ネットワーク、mTLS)
|
v
app-b Podのistio-proxy (Envoy) <- L4+L7処理 (ホップ2)
| (3) mTLS復号、認可チェック、L7テレメトリ
v
app-bコンテナ
プロキシホップ: 2 (両側とも常にL7パース)
Ambientモードのリクエストパス — L4のみ必要な場合
[Ambient, waypointなし] app-a (Node A) -> app-b (Node B) TCP/HTTP呼び出し
app-aコンテナ
| (1) アウトバウンド、istio-cniルールがノードのztunnelへリダイレクト
v
Node A ztunnel <- L4処理 (ホップ1)
| (2) HBONEトンネル確立 (mTLS, HTTP/2 CONNECT, :15008)
v
Node B ztunnel <- L4処理 (ホップ2)
| (3) 復号、L4認可チェック後にPodへ配送
v
app-bコンテナ
プロキシホップ: 2 (ただし両方とも軽量L4 — HTTPパースなし)
Ambientモードのリクエストパス — waypoint経由
[Ambient + waypoint] app-a -> app-b (app-bのネームスペースにwaypointあり)
app-aコンテナ
v
Node A ztunnel ── HBONE ──> waypoint Pod (Envoy) <- L7処理
| HTTPルーティング、リトライ、
| L7認可、テレメトリ
v
── HBONE ──> 宛先ノードのztunnel
v
app-bコンテナ
プロキシホップ: 3 (ztunnel -> waypoint -> ztunnel)
重要: waypointは「宛先側」のリソース — 宛先サービスのポリシーを執行
ここで重要な設計原則を1つ押さえておく必要があります。Ambientにおいてwaypointは宛先(サービス提供者)側に属します。サイドカーモデルではクライアント側のプロキシがルーティングとリトライを実行していましたが、Ambientでは宛先サービスを所有するチームが、自分のサービスのL7ポリシーを自分のwaypointで執行します。ポリシーの所有権が明確になる利点がありますが、サイドカーでクライアント側ポリシーに依存していた設定(例: 呼び出し元ごとに異なるタイムアウト)は再設計が必要になる場合があります。
機能パリティの現状 — 2026年時点
AmbientがGAに到達して以降、リリースを重ねるごとにサイドカーとの機能差は急速に縮まりました。2026年時点で私が確認した範囲の状況です(正確な状態は、ご使用のバージョンの公式ドキュメントで再確認してください)。
| 機能 | サイドカー | Ambient | 備考 |
|---|---|---|---|
| mTLS (メッシュ内暗号化) | 対応 | 対応 | ztunnelがL4で提供 |
| L4 AuthorizationPolicy | 対応 | 対応 | ztunnelで執行 |
| L7 AuthorizationPolicy | 対応 | 対応 | waypointが必要 |
| HTTPルーティング/カナリア | 対応 | 対応 | waypointが必要 |
| リトライ/タイムアウト/サーキットブレーカー | 対応 | 対応 | waypointが必要 |
| RequestAuthentication (JWT) | 対応 | 対応 | waypointが必要 |
| マルチクラスタ | 成熟 | 進行中 | Ambientマルチクラスタはアルファ→ベータ段階で発展中 |
| VMワークロードの編入 | 対応 | 限定的 | サイドカーが優位な領域 |
| EnvoyFilterカスタマイズ | 対応 | 部分的 | waypoint対象に一部のみ適用可能 |
| Sidecarリソース(スコープ縮小) | 対応 | 不要 | ztunnelのオンデマンド構成で代替 |
要約すると、単一クラスタでのmTLS + L4/L7ポリシー + トラフィック管理という中核シナリオはパリティに到達しています。差が残るのは、マルチクラスタの成熟度、VM編入、EnvoyFilterレベルの深いカスタマイズです。
リソース・性能比較 — 計算で確かめる
先ほどの500 Podの例をAmbientで再計算してみましょう。
前提:
- Pod 500個、ノード20台
- ztunnel 1個あたりのメモリ: 平均50MiB (接続数で変動、L4のみ処理)
- L7ポリシーが必要なネームスペース: 5個
- waypoint 1個あたり: replica 2、各200MiB (Envoy、HPAで拡張)
Ambientの総オーバーヘッド:
ztunnel = 20ノード x 50MiB = 1,000MiB ≈ 1GiB
waypoint = 5ns x 2replica x 200MiB = 2,000MiB ≈ 2GiB
合計 ≈ 3GiB
サイドカーモデル: ≈ 58.6GiB (先ほどの計算)
削減: 約95% (このシナリオの場合)
もちろん、この計算はAmbientに有利なシナリオです。誠実に逆方向も検討すべきです。
- レイテンシ: L4パス(ztunnelのみ経由)はサイドカーより速いか同等です。しかしwaypoint経由のパスはホップが3つあるため、サイドカー(ホップ2)より長くなる可能性があります。waypointが別のノードにあれば、ノード間の往復が追加されます。
- 障害範囲: サイドカーはプロキシ障害が該当Pod 1つに限定されます。ztunnelが死ぬと、そのノードのすべてのメッシュトラフィックが影響を受けます。ztunnelはそのために単純かつ安定的に設計されていますが、ノード単位の障害ドメインであるという事実は、運用設計(PodDisruptionBudget、優先度クラス、モニタリング)に反映する必要があります。
- ノイジーネイバー: 1つのノード上の複数テナントのトラフィックが同じztunnelを共有するため、極端なトラフィックを発生させるワークロードが、同じノードのワークロードのメッシュ経路に影響を与える可能性があります。
移行戦略 — ネームスペース単位の段階的移行
サイドカーからAmbientへの移行は、ビッグバンではなくネームスペース単位の段階的移行が定石です。Istioは同じメッシュ内でサイドカーワークロードとAmbientワークロードの混在運用をサポートしており、両モード間の通信もmTLSで相互運用されます。
推奨の移行順序:
フェーズ0: 事前点検
- IstioをAmbient対応の安定バージョンにアップグレード
- istio-cni、ztunnelコンポーネントをインストール (既存のサイドカー
トラフィックに影響なし)
- EnvoyFilterの使用箇所を全数調査 — Ambient非互換の項目を特定
フェーズ1: 低リスクのネームスペースを1つ選定 (社内ツール、ステージング)
- 該当nsワークロードのサイドカーインジェクションラベルを削除 + rollout restart
- istio.io/dataplane-mode=ambient ラベルを付与
- L7ポリシーがあった場合はwaypointをデプロイしポリシーを再バインド
- 1~2週間観察: mTLSメトリクス、エラー率、p99レイテンシ
フェーズ2: トラフィックパターンが単純な(L4中心の)ネームスペースへ拡大
- waypointなしでztunnelだけで運用できる領域から
フェーズ3: L7ポリシーが複雑な中核サービス
- waypointの容量算定(HPA)、ポリシー動作検証後に移行
フェーズ4: サイドカー残存領域の確定
- VM連携、EnvoyFilter依存のワークロードはサイドカー維持を決定可能
- 混在運用を公式な状態として文書化
移行中に最もよくあるミスは、サイドカーインジェクションラベルを残したままambientラベルを付けることです。1つのネームスペースで両モードが同時に有効になってはいけないため、移行スクリプトではラベルの状態を必ずアトミックに管理する必要があります。
# 移行前の状態確認 — 2つのラベルが共存してはならない
kubectl get namespace payments -o jsonpath='{.metadata.labels}'
# サイドカーインジェクションの解除 (revisionラベル使用時は該当ラベルを削除)
kubectl label namespace payments istio-injection-
# Podからサイドカーを除去
kubectl rollout restart deployment -n payments
# 再起動完了後にambientへ編入
kubectl label namespace payments istio.io/dataplane-mode=ambient
インストール実践
HelmでAmbientプロファイルをインストール
helm repo add istio https://istio-release.storage.googleapis.com/charts
helm repo update
# 1) CRDおよびベース
helm install istio-base istio/base -n istio-system --create-namespace --wait
# 2) istiod — ambientプロファイル
helm install istiod istio/istiod -n istio-system \
--set profile=ambient --wait
# 3) CNIノードエージェント — トラフィックリダイレクション担当
helm install istio-cni istio/cni -n istio-system \
--set profile=ambient --wait
# 4) ztunnel DaemonSet
helm install ztunnel istio/ztunnel -n istio-system --wait
istioctlを好む場合は1行でも可能です。
istioctl install --set profile=ambient --skip-confirmation
waypointのデプロイ
waypointはKubernetes Gateway APIのGatewayリソースとして宣言します。istioctlのヘルパーを使うか、YAMLを直接適用します。
# ネームスペース用waypointを作成 + 該当nsのトラフィックがwaypointを使うよう編入
istioctl waypoint apply -n payments --enroll-namespace
# 上記コマンドと同等の宣言的YAML
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: waypoint
namespace: payments
labels:
istio.io/waypoint-for: service # service | workload | all
spec:
gatewayClassName: istio-waypoint
listeners:
- name: mesh
port: 15008
protocol: HBONE
---
# ネームスペースがこのwaypointを使うようラベリング (enroll-namespaceと同じ効果)
# kubectl label ns payments istio.io/use-waypoint=waypoint
特定のサービスだけwaypointを経由させたい場合は、Serviceオブジェクトにistio.io/use-waypointラベルを付けます。ネームスペースのラベルより細かい単位が優先されます。
Ciliumとの関係 — 衝突か共存か
CiliumをCNIとして使うクラスタでAmbientを動かせるかは、よく受ける質問です。結論から言うと可能ですが、役割分担を明確にする必要があります。
- CNI互換性: istio-cniはCNIプラグインチェーンに割り込む方式なので、Ciliumの上で動作します。ただし、Cilium側の設定で互換に必要なオプション(例: ソケットベースのロードバランシングをホストネームスペースに限定する — socketLB.hostNamespaceOnly)を調整すべき事例が知られているため、両プロジェクトの互換性ドキュメントをバージョンに合わせて確認してください。
- 重複する領域: Ciliumも独自にトランスポート暗号化(WireGuard/IPsec)、L4ネットワークポリシー、L7可視性(Hubble)を提供します。Istio Ambientと機能が重なる部分があるため、「暗号化はどのレイヤーが担当するのか」「L4ポリシーはNetworkPolicyかAuthorizationPolicyか」をチームとして1つに決めなければ、二重ポリシーによるデバッグ地獄に陥ります。
- 実用的な分担案: CiliumはCNI/ネットワークポリシー/ノードレベルの可視性、Istio Ambientはワークロードアイデンティティに基づくmTLSとL7トラフィック管理 — このようにレイヤーで分ける構成が現場では最も無難でした。
サイドカーが依然として適している場合
Ambientがデフォルトになりつつある流れの中でも、次の条件下ではサイドカーが依然として合理的です。
- EnvoyFilterで深いカスタマイズをしているワークロード — Lua/WASMフィルター、非標準プロトコル処理などはサイドカー側が自由です。
- VMワークロードがメッシュの一級市民であるべき環境 — VM編入はサイドカーモデルの成熟度が高いです。
- Pod単位の障害分離が契約レベルで要求される場合 — ノード共有プロキシ(ztunnel)が規制・監査要件上受け入れられない組織があります。
- クライアント側のL7ポリシーに深く依存するアーキテクチャ — 呼び出し元ごとのルーティング/リトライロジックを短期間で再設計できない場合。
- 高度なマルチクラスタトポロジーを現在運用中の場合 — Ambientマルチクラスタが自分の要求レベルの成熟度に到達しているか、バージョンごとに検証が必要です。
意思決定ツリー
新規メッシュ構築か?
├─ はい → EnvoyFilter/VM/高度なマルチクラスタの要件があるか?
│ ├─ ない → Ambientで開始 (推奨デフォルト)
│ └─ ある → 該当ワークロードのみサイドカー、残りはAmbientで混在
└─ いいえ (既存のサイドカーメッシュを運用中)
→ サイドカーの運用負担(リソース/アップグレード)は大きいか?
├─ 大きい → ネームスペース単位の段階的移行を開始
│ L4中心のnsから → L7のnsはwaypoint検証後
└─ 小さい → 現状維持 + 新規nsのみAmbientへ (漸進的収束)
トラブルシューティング
ztunnelの状態とログの確認
# ztunnel Podの確認
kubectl get pods -n istio-system -l app=ztunnel -o wide
# 特定ノードのztunnelログ — ワークロード編入/HBONE接続イベントの確認
kubectl logs -n istio-system ztunnel-abcde --tail=100
# ztunnelが認識しているワークロード一覧 (istioctl)
istioctl ztunnel-config workloads
istioctl ztunnel-config services
istioctl ztunnel-config certificates # ワークロード証明書の発行状態
ztunnel-config workloadsの出力でPROTOCOL列がHBONEなら、そのワークロードはメッシュに編入されており、TCPなら平文パススルー(メッシュ外)の状態です。「ラベルは付けたのにmTLSが効かない」類の問題は、ほとんどここで判別できます。
istioctl analyzeとよくある症状
# 設定の整合性診断 — モード混在、waypoint未バインドなどを検出
istioctl analyze -n payments
# waypointがポリシー/ルートを受け取ったか確認 (waypointはEnvoyなのでproxy-configが使える)
istioctl proxy-config routes deploy/waypoint -n payments
| 症状 | よくある原因 | 確認方法 |
|---|---|---|
| 編入後も平文通信 | dataplane-modeラベルのタイポ、istio-cni未インストール | ztunnel-config workloadsのPROTOCOL列 |
| L7ポリシーが効かない | waypoint未デプロイまたはuse-waypoint未バインド | Gatewayリソースの状態、istioctl analyze |
| 断続的な接続切断 | ztunnelの再起動(OOM)、PDB未設定 | ztunnelの再起動回数、リソース使用量 |
| Job Podのハング | (Ambientでは該当なし — サイドカー残存nsか確認) | ネームスペースのモードラベル |
| サイドカーとambientの混乱 | 1つのnsにインジェクションラベルとambientラベルが共存 | nsラベルの全数点検 |
導入チェックリスト
- IstioのバージョンがAmbient GA以降の安定バージョンであることを確認した
- istio-cniと既存CNI(Ciliumなど)の互換設定をバージョンのドキュメントで検証した
- EnvoyFilter、VM編入、マルチクラスタの依存関係を全数調査した
- 移行対象ネームスペースのモードラベルをアトミックに管理する手順を作った
- L7ポリシーが必要なネームスペースを特定し、waypointの容量(HPA)を算定した
- ztunnelにPodDisruptionBudgetとモニタリング(再起動、メモリ)を設定した
- 混在運用期間のmTLS相互運用をステージングで検証した
- 移行フェーズごとの観察指標(エラー率、p99、mTLS比率)とロールバック手順を文書化した
- ノード共有プロキシの構造がセキュリティ・監査要件に適合するか検討した
おわりに
サイドカーモデルはサービスメッシュを大衆化しましたが、「すべてのPodにフルL7プロキシ」というコスト構造は、メッシュ導入の最大の障壁でもありました。AmbientはL4(ztunnel)とL7(waypoint)を分離してこのコストを使った分だけ払う構造に変え、Pod再起動なしのメッシュ編入とインフラレイヤーでのアップグレードという運用上の利点まで加えました。
2026年の現実的な結論はこうです。新規構築はAmbientをデフォルトとして検討しつつ、EnvoyFilter・VM・高度なマルチクラスタのようなサイドカー優位の領域があるなら、混在運用を恐れないでください。既存のメッシュはネームスペース単位でゆっくり、指標を見ながら移せばよいのです。アーキテクチャ選定は一度きりの決定ではなく、ワークロードごとの分類作業に近いものです。