- はじめに
- Istio Ambient Meshのアーキテクチャを理解する
- ztunnel: L4処理レイヤー
- Waypoint Proxy: L7処理レイヤー
- SidecarとAmbientの比較
- インストールと構成
- トラフィックポリシーの構成
- オブザーバビリティの統合
- 移行戦略
- トラブルシューティング
- プロダクションチェックリスト
- 障害事例と復旧手順
- 参考資料
はじめに
サービスメッシュ（Service Mesh）は、マイクロサービスアーキテクチャにおいてサービス間の通信を透過的に管理する中核的なインフラストラクチャレイヤーです。Istioはこの分野で最も広く使われているオープンソースプロジェクトですが、従来のサイドカープロキシモデルは、運用の複雑さとリソースオーバーヘッドという根本的な課題を抱えていました。
すべてのPodにEnvoyサイドカーを注入する方式は、Pod当たり50〜100MBのメモリオーバーヘッド、2〜5秒の起動遅延、サイドカーのアップグレード時にワークロード全体のローリングリスタートが必要になるなど、無視できないコストを伴います。数千個のPodを運用する大規模クラスタでは、サイドカー自体が相当なインフラコストになります。
Istio Ambient Meshはこの問題を根本から解決します。サイドカーを完全に排除し、ノードレベルの共有プロキシ（ztunnel）と選択的なL7プロキシ（waypoint proxy）という2層アーキテクチャを導入することで、メモリ使用量90%以上の削減、CPU使用量50%以上の削減を達成します。Istio 1.22でBetaに到達して以降、プロダクション環境での採用が急速に増えています。
本記事では、Ambient Meshのアーキテクチャ原理からインストール、トラフィックポリシー、オブザーバビリティ、サイドカーからの移行戦略、そしてプロダクション運用で遭遇する障害事例と復旧手順まで、実践中心に解説します。
Istio Ambient Meshのアーキテクチャを理解する
2層データプレーン
Ambient Meshの中核となる設計思想は 関心の分離（separation of concerns）です。従来のサイドカーモデルでは1つのEnvoyプロキシがL4からL7まですべての機能を処理していましたが、Ambient Meshはこれを2つの明確なレイヤーに分離します。
+------------------------------------------------------------------+
| Istio Ambient Mesh アーキテクチャ |
+------------------------------------------------------------------+
| |
| [Service A Pod] [Service B Pod] [Service C Pod] |
| | | | |
| v v v |
| +----------------------------------------------------------+ |
| | ztunnel (DaemonSet, 各ノード) | |
| | - mTLS トンネリング (HBONE) | |
| | - L4 認証 / 認可 | |
| | - L4 テレメトリ | |
| | - TCP 接続管理 | |
| +----------------------------------------------------------+ |
| | |
| | HBONE (HTTP CONNECT ベースのトンネリング) |
| v |
| +----------------------------------------------------------+ |
| | Waypoint Proxy (任意、ネームスペース/SA単位) | |
| | - HTTP ルーティング | |
| | - L7 認証 / 認可ポリシー | |
| | - L7 テレメトリ | |
| | - トラフィックミラーリング、カナリアデプロイ | |
| | - ヘッダーベースのルーティング | |
| +----------------------------------------------------------+ |
| | |
| | HBONE |
| v |
| +----------------------------------------------------------+ |
| | ztunnel (宛先ノード) | |
| +----------------------------------------------------------+ |
| | |
| v |
| [Destination Pod] |
| |
+------------------------------------------------------------------+
L4 Secure Overlay (ztunnel): すべてのメッシュトラフィックに対してデフォルトで有効になります。mTLS暗号化、L4アクセス制御、TCPレベルのテレメトリを提供します。極めて軽量なRustベースのプロキシとして実装されています。
L7 Processing (Waypoint Proxy): HTTPルーティング、ヘッダーベースのポリシー、gRPCメトリクスの収集など、L7機能が必要な場合にのみ選択的にデプロイされます。標準のEnvoyプロキシを使用します。
この設計により、L7機能を必要としないサービス（全サービスのかなりの割合）はztunnelだけでメッシュのセキュリティとオブザーバビリティを十分に確保でき、L7プロキシのコストを支払わずに済みます。
トラフィックフローの詳細
Ambient Meshでトラフィックが処理される過程を段階的に見ていきます。
L4のみのフロー (Waypointなし):
Pod A ---> ztunnel(ノード1) ===HBONE===> ztunnel(ノード2) ---> Pod B
L7処理が必要なフロー:
Pod A ---> ztunnel(ノード1) ===HBONE===> Waypoint Proxy ===HBONE===> ztunnel(ノード2) ---> Pod B
- 送信元Podから出ていくトラフィックを、同じノードのztunnelが透過的にインターセプトします
- ztunnelはHBONE（HTTP CONNECTベース）プロトコルでトラフィックを暗号化してトンネリングします
- L7ポリシーが設定された宛先であれば、まずwaypoint proxyへ転送します
- waypoint proxyでL7ポリシー（ルーティング、認可など）を適用したうえで、宛先ノードのztunnelへ転送します
- 宛先ノードのztunnelが復号して宛先Podへ転送します
ztunnel: L4処理レイヤー
ztunnelとは
ztunnel（Zero Trust Tunnel）は、Ambient Meshの基盤レイヤーを構成する軽量プロキシです。各ノードにDaemonSetとしてデプロイされ、そのノードのすべてのワークロードトラフィックを処理します。
主な特性:
- Rustで記述: C/C++レベルの性能を提供しながら、メモリ安全性を保証します
- 意図的に限定されたスコープ: L3/L4機能だけを処理するよう設計されており、攻撃対象領域が小さくなっています
- HTTPトラフィックをパースしない: ワークロードのHTTPヘッダーを読み取ったり書き換えたりしないため、セキュリティが高くなります
- HBONEプロトコル: HTTP CONNECTベースのトンネリングプロトコルでmTLS通信を実装します
ztunnelの機能詳細
# ztunnelが提供する機能の範囲
ztunnel_capabilities:
security:
- mTLSの自動暗号化/復号
- SPIFFEベースのワークロードID発行
- L4 AuthorizationPolicyの適用
networking:
- TCP接続のプロキシ
- HBONEトンネリング
- ロードバランシング (L4)
observability:
- TCP接続メトリクス (バイト、接続数、継続時間)
- L4アクセスログ
- Prometheusメトリクスの公開
not_supported:
- HTTPルーティング
- ヘッダーベースのポリシー
- gRPCプロトコルのパース
- トラフィックのミラーリング/分割
ztunnelのリソースプロファイル
ztunnelはサイドカーEnvoyとは比較にならないほど軽量です。一般的なプロダクション環境でのリソース使用量を比較すると、次のようになります。
| 項目 | Envoyサイドカー (Pod当たり) | ztunnel (ノード当たり) |
|---|---|---|
| メモリ基本 | 50〜100MB | 20〜40MB |
| CPU基本 | 10〜50m | 10〜30m |
| 100個Podクラスタの総コスト | 5〜10GBメモリ | 60〜120MB (3ノード基準) |
| バイナリサイズ | 約40MB | 約10MB |
ztunnelの状態確認
# ztunnel DaemonSetの状態確認
kubectl get daemonset -n istio-system ztunnel
# ztunnel Podのログ確認
kubectl logs -n istio-system -l app=ztunnel --tail=50
# ztunnelプロキシの状態確認 (特定ノード)
kubectl exec -n istio-system $(kubectl get pod -n istio-system -l app=ztunnel --field-selector spec.nodeName=worker-1 -o jsonpath='{.items[0].metadata.name}') -- curl -s localhost:15000/config_dump
# ztunnelが管理するワークロード一覧の確認
kubectl exec -n istio-system $(kubectl get pod -n istio-system -l app=ztunnel -o jsonpath='{.items[0].metadata.name}') -- curl -s localhost:15020/debug/workloadz
Waypoint Proxy: L7処理レイヤー
Waypoint Proxyの役割
Waypoint Proxyは、L7レベルのトラフィック管理が必要な場合にのみデプロイするオプションのコンポーネントです。標準のEnvoyプロキシエンジンを使用し、ネームスペースまたはサービスアカウント単位でデプロイされます。
ztunnelとの主な違いは次のとおりです。
- HTTP/gRPCプロトコルを理解し、ヘッダーをパースします
- リクエスト単位のルーティング、リトライ、タイムアウトを適用します
- L7 AuthorizationPolicy（パス、メソッドベース）を実行します
- HTTPメトリクスと分散トレーシングのデータを収集します
Waypoint Proxyのデプロイ
# ネームスペースにwaypoint proxyをデプロイ
istioctl waypoint apply -n my-namespace
# 特定のサービスアカウント用のwaypointをデプロイ
istioctl waypoint apply -n my-namespace --name sa-waypoint --for service
# waypoint proxyの状態確認
kubectl get gateway -n my-namespace
Waypoint ProxyはKubernetes Gateway APIのGatewayリソースとして管理されます。
# waypoint proxy Gatewayリソースの例
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: my-namespace-waypoint
namespace: my-namespace
labels:
istio.io/waypoint-for: service
spec:
gatewayClassName: istio-waypoint
listeners:
- name: mesh
port: 15008
protocol: HBONE
Waypoint Proxyのスケーリング
プロダクション環境では、waypoint proxyのリソースとレプリカ数を適切に調整する必要があります。
# waypoint proxyに対するHPA設定
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: my-namespace-waypoint
namespace: my-namespace
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: my-namespace-waypoint
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
- type: Resource
resource:
name: memory
target:
type: Utilization
averageUtilization: 80
SidecarとAmbientの比較
2つのモードをさまざまな観点から比較します。同じクラスタでサイドカーモードとambientモードをネームスペース単位で混在させることはできますが、同じネームスペースに2つのモードを同時に適用してはいけません。
| 比較項目 | サイドカーモード | Ambientモード |
|---|---|---|
| プロキシ配置 | Pod当たりEnvoy 1個 | ノード当たりztunnel + 選択的なwaypoint |
| メモリオーバーヘッド | Pod当たり50〜100MB | ノード当たり20〜40MB (ztunnel) |
| CPUオーバーヘッド | Pod当たり10〜50m | ノード当たり10〜30m (ztunnel) |
| 100 Podの総コスト | 5〜10GBメモリ | 60〜120MB (3ノード基準) |
| ネットワーク遅延 | 送信/受信で各1ホップ追加 | L4: 同程度、L7: waypointの追加ホップ |
| Pod起動への影響 | 2〜5秒の遅延 (サイドカー初期化) | 影響なし |
| メッシュへの追加方法 | Podの再起動が必要 (サイドカー注入) | ネームスペースのラベル追加のみ |
| メッシュからの除外方法 | Podの再起動が必要 | ラベルの削除 (再起動不要) |
| L7ポリシーの適用 | すべてのトラフィックにデフォルト適用 | waypointのデプロイ後にのみ適用 |
| ワークロードの分離 | Pod単位で完全に分離 | ノード単位で共有 (ztunnel) |
| EnvoyFilterのサポート | 完全サポート | 限定的 (waypointでのみ可能) |
| マルチクラスタ | 完全サポート | 改善中 |
| 成熟度 | GA (プロダクションで安定) | Beta (v1.22+、プロダクション推奨) |
| アップグレード方式 | Podのローリングリスタートが必要 | ztunnel DaemonSetのローリングアップデート |
どちらのモードを選ぶべきか
Ambientモードが適しているケース:
- 大規模クラスタでリソース効率が重要な場合
- 大部分のサービスがL4セキュリティ（mTLS、ネットワークポリシー）だけを必要とする場合
- Podを再起動せずにメッシュを段階的に導入したい場合
- サイドカー管理の運用負担を減らしたい場合
サイドカーモードが適しているケース:
- Pod単位の完全なネットワーク分離が必要な場合
- EnvoyFilterを活用したきめ細かいプロキシのカスタマイズが必要な場合
- マルチクラスタまたはVMネットワーキングが中心となる場合
- L7ポリシーをすべてのサービスにデフォルトで適用する必要がある場合
インストールと構成
事前要件
# Kubernetesクラスタのバージョン確認 (1.27+ 推奨)
kubectl version --short
# istioctlのインストール (最新バージョン)
curl -L https://istio.io/downloadIstio | sh -
cd istio-*
export PATH=$PWD/bin:$PATH
# istioctlのバージョン確認
istioctl version
AmbientプロファイルでIstioをインストール
# ambientプロファイルでIstioをインストール
istioctl install --set profile=ambient --skip-confirmation
# インストールの確認
kubectl get pods -n istio-system
# 想定される出力:
# NAME READY STATUS RESTARTS AGE
# istiod-xxxx 1/1 Running 0 2m
# ztunnel-xxxxx 1/1 Running 0 2m
# ztunnel-yyyyy 1/1 Running 0 2m
# ztunnel-zzzzz 1/1 Running 0 2m
# istio-cni-node-xxxxx 1/1 Running 0 2m
# istio-cni-node-yyyyy 1/1 Running 0 2m
# istio-cni-node-zzzzz 1/1 Running 0 2m
ambientプロファイルは次のコンポーネントをインストールします:
- istiod: コントロールプレーン（Pilot、Citadel、Galleyを統合）
- ztunnel: 各ノードのL4プロキシ（DaemonSet）
- istio-cni: トラフィックリダイレクトのためのCNIプラグイン（DaemonSet）
ネームスペースをメッシュに追加
# ネームスペースをambientメッシュに追加 (Podの再起動は不要!)
kubectl label namespace my-app istio.io/dataplane-mode=ambient
# ラベルの確認
kubectl get namespace my-app --show-labels
# 特定のPodだけをメッシュから除外
kubectl label pod my-pod -n my-app istio.io/dataplane-mode=none
# メッシュからネームスペースを除外 (Podの再起動は不要!)
kubectl label namespace my-app istio.io/dataplane-mode-
注意事項: 1つのネームスペースに、サイドカーモード（istio-injection=enabled）とambientモード（istio.io/dataplane-mode=ambient）のラベルを同時に適用してはいけません。
Helmを使ったインストール
プロダクション環境では、Helmを使ってきめ細かく設定を管理することが推奨されます。
# Istio Helmリポジトリの追加
helm repo add istio https://istio-release.storage.googleapis.com/charts
helm repo update
# istio-base (CRDs) のインストール
helm install istio-base istio/base -n istio-system --create-namespace
# istiodのインストール (ambientプロファイル)
helm install istiod istio/istiod -n istio-system \
--set profile=ambient \
--set pilot.resources.requests.memory=256Mi \
--set pilot.resources.requests.cpu=200m
# ztunnelのインストール
helm install ztunnel istio/ztunnel -n istio-system \
--set resources.requests.memory=64Mi \
--set resources.requests.cpu=50m
# istio-cniのインストール
helm install istio-cni istio/cni -n istio-system \
--set ambient.enabled=true
トラフィックポリシーの構成
L4 AuthorizationPolicy
ztunnelで処理されるL4レベルのアクセス制御ポリシーです。Waypoint proxyがなくても動作します。
# L4 AuthorizationPolicy: 特定のサービスにだけアクセスを許可
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
name: allow-frontend-to-backend
namespace: my-app
spec:
targetRefs:
- kind: Service
group: ''
name: backend
action: ALLOW
rules:
- from:
- source:
principals:
- 'cluster.local/ns/my-app/sa/frontend'
to:
- operation:
ports: ['8080']
---
# L4のデフォルト拒否ポリシー
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
name: deny-all
namespace: my-app
spec:
targetRefs:
- kind: Service
group: ''
name: backend
action: DENY
rules: []
L7 AuthorizationPolicy (Waypointが必要)
HTTPパスやメソッドに基づくきめ細かいアクセス制御は、waypoint proxyをデプロイした後に利用できます。
# まずwaypoint proxyをデプロイ
# istioctl waypoint apply -n my-app
# L7 AuthorizationPolicy: HTTPパスに基づく制御
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
name: api-access-control
namespace: my-app
spec:
targetRefs:
- kind: Service
group: ''
name: api-server
action: ALLOW
rules:
- from:
- source:
principals:
- 'cluster.local/ns/my-app/sa/web-frontend'
to:
- operation:
methods: ['GET']
paths: ['/api/v1/products/*']
- from:
- source:
principals:
- 'cluster.local/ns/my-app/sa/admin-service'
to:
- operation:
methods: ['GET', 'POST', 'PUT', 'DELETE']
paths: ['/api/v1/*']
VirtualServiceを活用したトラフィック分割
# カナリアデプロイのためのトラフィック分割 (Waypointが必要)
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
name: reviews-canary
namespace: my-app
spec:
hosts:
- reviews
http:
- match:
- headers:
x-canary:
exact: 'true'
route:
- destination:
host: reviews
subset: v2
weight: 100
- route:
- destination:
host: reviews
subset: v1
weight: 90
- destination:
host: reviews
subset: v2
weight: 10
---
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
name: reviews-dr
namespace: my-app
spec:
host: reviews
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
PeerAuthenticationの設定
# Strict mTLSの適用 (ambientモードではデフォルトで有効)
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
name: strict-mtls
namespace: my-app
spec:
mtls:
mode: STRICT
オブザーバビリティの統合
Prometheusメトリクスの収集
Ambient Meshは、ztunnelとwaypoint proxyの両方がPrometheusメトリクスを公開します。
# Prometheus ServiceMonitor for ztunnel
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: ztunnel-monitor
namespace: istio-system
spec:
selector:
matchLabels:
app: ztunnel
endpoints:
- port: http-monitoring
path: /metrics
interval: 15s
---
# Prometheus ServiceMonitor for waypoint proxies
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: waypoint-monitor
namespace: my-app
spec:
selector:
matchLabels:
gateway.istio.io/managed: istio.io-mesh-controller
endpoints:
- port: http-envoy-prom
path: /stats/prometheus
interval: 15s
主要メトリクスのモニタリング
# ztunnelメトリクスの確認
kubectl exec -n istio-system $(kubectl get pod -n istio-system -l app=ztunnel -o jsonpath='{.items[0].metadata.name}') -- curl -s localhost:15020/metrics | grep istio_tcp
# 主要なztunnelメトリクス:
# istio_tcp_connections_opened_total - オープンしたTCP接続数
# istio_tcp_connections_closed_total - クローズしたTCP接続数
# istio_tcp_sent_bytes_total - 送信バイト
# istio_tcp_received_bytes_total - 受信バイト
# istio_tcp_connection_duration_seconds - 接続の継続時間
# waypoint proxyメトリクスの確認 (L7メトリクスを含む)
kubectl exec -n my-app $(kubectl get pod -n my-app -l gateway.istio.io/managed=istio.io-mesh-controller -o jsonpath='{.items[0].metadata.name}') -- curl -s localhost:15090/stats/prometheus | grep istio_request
# 主要なwaypointメトリクス:
# istio_requests_total - 総リクエスト数 (L7)
# istio_request_duration_milliseconds - リクエスト遅延 (L7)
# istio_request_bytes - リクエストサイズ
# istio_response_bytes - レスポンスサイズ
Kialiの統合
KialiはAmbient Meshに対応しており、ztunnelとwaypoint proxyを含むサービスグラフを可視化できます。
# Kialiのインストール (Ambient対応を含む)
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.24/samples/addons/kiali.yaml
# Kialiダッシュボードへのアクセス
istioctl dashboard kiali
Grafanaダッシュボード
# Grafana + Prometheusスタックのインストール
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.24/samples/addons/prometheus.yaml
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.24/samples/addons/grafana.yaml
# Grafanaダッシュボードへのアクセス
istioctl dashboard grafana
Ambient Mesh用のGrafanaダッシュボードで確認すべき主要パネル:
- ztunnelのノード別TCP接続数とバイトトラフィック
- Waypoint proxy別のHTTPリクエスト率とエラー率
- mTLSハンドシェイクの成功/失敗率
- HBONEトンネルの遅延時間
移行戦略
サイドカーからAmbientモードへの移行
既存のIstioサイドカーモードからAmbientモードへの移行は、段階的に実施する必要があります。2つのモードは同じクラスタで共存できるため、ネームスペース単位で段階的に移行できます。
ステップ1: 事前準備
# 現在のIstioバージョンがambientをサポートしているか確認 (1.22+)
istioctl version
# ambientプロファイルのコンポーネントをインストール (既存のistiodは維持)
istioctl install --set profile=ambient --skip-confirmation
# ztunnelとistio-cniが正常に動作しているか確認
kubectl get daemonset -n istio-system ztunnel
kubectl get daemonset -n istio-system istio-cni-node
ステップ2: 重要度の低いネームスペースから移行
# テスト用ネームスペースでまず検証
# 1. サイドカーラベルの削除
kubectl label namespace test-app istio-injection-
# 2. ambientラベルの追加
kubectl label namespace test-app istio.io/dataplane-mode=ambient
# 3. 既存のサイドカーを削除するためPodを再起動
kubectl rollout restart deployment -n test-app
# 4. サイドカーが削除されztunnel経由で通信しているか確認
kubectl get pods -n test-app
# すべてのPodが1/1 (サイドカーなし) と表示されるはず
# 5. mTLS通信の確認
istioctl proxy-status
ステップ3: L7機能が必要なネームスペースにWaypointをデプロイ
# これまでL7ポリシーを使っていたネームスペースにwaypointをデプロイ
istioctl waypoint apply -n test-app
# VirtualService、AuthorizationPolicyなど既存のL7ポリシーが
# waypoint経由で正常に動作するか確認
kubectl get gateway -n test-app
ステップ4: 検証後にプロダクションのネームスペースを移行
# プロダクションのネームスペースを移行 (同じ手順)
kubectl label namespace production istio-injection-
kubectl label namespace production istio.io/dataplane-mode=ambient
kubectl rollout restart deployment -n production
# waypointが必要な場合はデプロイ
istioctl waypoint apply -n production
移行時の注意事項
HBONE互換性: サイドカーモードのPodがambientモードのPodと通信するには、サイドカーに ENABLE_HBONE フラグが設定されている必要があります。移行前にサイドカーをHBONE対応バージョンに更新し、再起動する必要があります。
Waypointの認識: サイドカーはwaypoint proxyを認識しません。サイドカーモードのクライアントがambientモードのサーバーへリクエストを送ると、waypointを迂回することがあります。可能な限り、同じ通信経路上のサービスを同じモードへ移行することが推奨されます。
CNI互換性: CiliumをCNIとして使う場合、Ciliumはデフォルトで他のCNIプラグインを削除しようとします。cni.exclusive=false を設定してこれを防ぐ必要があります。
トラブルシューティング
よくある問題と解決方法
問題1: Pod間の通信失敗（mTLSハンドシェイクエラー）
# 症状: Pod間の接続が拒否される、またはタイムアウトする
# 原因: ztunnelが正常に動作していない、または証明書の問題
# 診断1: ztunnelの状態確認
kubectl get pods -n istio-system -l app=ztunnel
kubectl logs -n istio-system -l app=ztunnel --tail=100 | grep -i error
# 診断2: 証明書の状態確認
istioctl proxy-status
# 診断3: ワークロードIDの確認
kubectl exec -n istio-system $(kubectl get pod -n istio-system -l app=ztunnel -o jsonpath='{.items[0].metadata.name}') -- curl -s localhost:15020/debug/workloadz
# 解決: ztunnelの再起動
kubectl rollout restart daemonset ztunnel -n istio-system
問題2: L7ポリシーが適用されない
# 症状: AuthorizationPolicyのHTTPパス/メソッドに基づくルールが無視される
# 原因: waypoint proxyがデプロイされていない、または正しく接続されていない
# 診断1: waypoint proxyの有無を確認
kubectl get gateway -n my-app
istioctl waypoint list -n my-app
# 診断2: waypoint proxy Podの状態確認
kubectl get pods -n my-app -l gateway.istio.io/managed=istio.io-mesh-controller
# 診断3: waypoint proxyのログ確認
kubectl logs -n my-app -l gateway.istio.io/managed=istio.io-mesh-controller --tail=100
# 解決: waypointの再デプロイ
istioctl waypoint delete -n my-app
istioctl waypoint apply -n my-app
問題3: CNIプラグインの競合
# 症状: ztunnelがトラフィックをインターセプトできず、Podがメッシュ外のように動作する
# 原因: istio-cniと既存のCNIプラグインの競合
# 診断: istio-cniのログ確認
kubectl logs -n istio-system -l k8s-app=istio-cni-node --tail=100
# 解決 (Cilium環境):
# Ciliumのexclusive CNI設定を無効化
helm upgrade cilium cilium/cilium -n kube-system \
--set cni.exclusive=false
# istio-cniの再起動
kubectl rollout restart daemonset istio-cni-node -n istio-system
問題4: メッシュ外部のサービスとの通信問題
# 症状: ambientメッシュ内のPodがメッシュ外部のサービスにアクセスできない
# 原因: ztunnelが外部トラフィックもインターセプトしてHBONEトンネリングを試みる
# 診断: ztunnelのログで外部宛先に関するエラーを確認
kubectl logs -n istio-system -l app=ztunnel --tail=200 | grep "external"
# 解決: ServiceEntryで外部サービスを明示的に登録
cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
name: external-api
namespace: my-app
spec:
hosts:
- api.external-service.com
location: MESH_EXTERNAL
ports:
- number: 443
name: https
protocol: TLS
resolution: DNS
EOF
問題5: ztunnelのメモリ使用量が急増
# 症状: ztunnel Podのメモリ使用量が継続的に増加する
# 原因: 大量の同時接続、またはメモリリーク
# 診断: 現在のメモリ使用量を確認
kubectl top pods -n istio-system -l app=ztunnel
# 診断: 接続数の確認
kubectl exec -n istio-system $(kubectl get pod -n istio-system -l app=ztunnel -o jsonpath='{.items[0].metadata.name}') -- curl -s localhost:15020/metrics | grep tcp_connections
# 解決: ztunnelのリソース制限を調整
helm upgrade ztunnel istio/ztunnel -n istio-system \
--set resources.limits.memory=256Mi \
--set resources.requests.memory=128Mi
プロダクションチェックリスト
Ambient Meshをプロダクション環境にデプロイする前に、必ず確認すべき項目です。
インストール前の確認
- Kubernetesクラスタのバージョンが1.27以上であることを確認
- Istioのバージョンが1.22以上（ambient Beta）であることを確認
- CNIプラグインの互換性を検証（Calico、Ciliumなど）
- Gateway API CRDがインストールされていることを確認
- ノードのリソース余裕を確認（ztunnel DaemonSet用）
ネットワーク設定
- 既存のサイドカーモードとambientモードのネームスペースが重複していないことを確認
- HBONEポート（15008）がノード間のファイアウォールで許可されていることを確認
- ztunnelのメトリクスポート（15020）にPrometheusからアクセスできることを確認
- メッシュ外部のサービスに対するServiceEntryが構成されていることを確認
セキュリティ設定
- PeerAuthenticationがSTRICT mTLSに設定されていることを確認
- L4 AuthorizationPolicyのデフォルト拒否ポリシーが設定されていることを確認
- L7ポリシーが必要なネームスペースにwaypoint proxyがデプロイされていることを確認
- SPIFFE IDに基づくサービス間アクセス制御が構成されていることを確認
オブザーバビリティ
- Prometheusがztunnelとwaypointのメトリクスを収集するよう設定されていることを確認
- Grafanaダッシュボードにambient mesh専用のパネルが構成されていることを確認
- Kialiがambientモードに対応したバージョンであることを確認
- アラートルールがztunnelの障害とwaypointのエラー率に対して設定されていることを確認
高可用性
- ztunnel DaemonSetのupdateStrategyがRollingUpdateであることを確認
- waypoint proxyのreplicasが最低2個以上であることを確認
- waypoint proxyにPodDisruptionBudgetが設定されていることを確認
- istiodのreplicasが最低2個以上であることを確認
移行（サイドカーから切り替える場合）
- 重要度の低いネームスペースで先に検証を完了していることを確認
- サイドカーモードのPodがHBONEに対応したバージョンであることを確認
- 既存のVirtualService/DestinationRuleがwaypointで正常に動作することを確認
- ロールバック手順が文書化されていることを確認
障害事例と復旧手順
事例1: ztunnel DaemonSetの更新中にサービスが中断
状況: ztunnel DaemonSetを更新する際、特定のノードで新しいztunnel Podが起動する前に既存のztunnel Podが終了し、そのノードのすべてのメッシュトラフィックが中断した。
原因: maxUnavailableの設定が高すぎる、または新しいztunnel Podの起動が遅延した。
復旧手順:
# 1. 影響を受けるノードの確認
kubectl get pods -n istio-system -l app=ztunnel -o wide
# 2. 更新の一時停止 (可能な場合)
kubectl rollout pause daemonset ztunnel -n istio-system
# 3. 影響を受けるノードでztunnelを手動で復旧
kubectl delete pod -n istio-system $(kubectl get pod -n istio-system -l app=ztunnel --field-selector spec.nodeName=affected-node -o jsonpath='{.items[0].metadata.name}')
# 4. ztunnelの復旧確認
kubectl get pods -n istio-system -l app=ztunnel -o wide
# 予防措置: maxUnavailableを1に設定
kubectl patch daemonset ztunnel -n istio-system -p '{"spec":{"updateStrategy":{"rollingUpdate":{"maxUnavailable":1}}}}'
事例2: Waypoint Proxyの過負荷によるL7ポリシーの遅延
状況: 特定のネームスペースのwaypoint proxyにトラフィックが集中し、レスポンス遅延が急増した。
原因: waypoint proxyのレプリカ数がトラフィック量に対して不足していた。
復旧手順:
# 1. waypoint proxyの状態確認
kubectl get pods -n affected-namespace -l gateway.istio.io/managed=istio.io-mesh-controller
kubectl top pods -n affected-namespace -l gateway.istio.io/managed=istio.io-mesh-controller
# 2. 即時のスケールアウト
kubectl scale deployment -n affected-namespace $(kubectl get deployment -n affected-namespace -l gateway.istio.io/managed=istio.io-mesh-controller -o jsonpath='{.items[0].metadata.name}') --replicas=5
# 3. HPA設定で自動スケーリングを適用 (上記のHPA例を参照)
# 4. 必要に応じて一時的にL7ポリシーをL4へ緩和
# waypointを削除するとL7ポリシーが無効になりL4(ztunnel)へフォールバック
# istioctl waypoint delete -n affected-namespace
# (注意: L7ポリシーがすべて無効になる)
事例3: サイドカーとAmbientの混在モードでの通信障害
状況: 移行中、サイドカーモードのネームスペースのサービスがambientモードのネームスペースのサービスを呼び出す際に、断続的に失敗した。
原因: サイドカーがHBONEプロトコルに対応していない古いバージョンであるか、サイドカーがwaypoint proxyを認識できずトラフィックを直接バックエンドへ送っていた。
復旧手順:
# 1. サイドカーのHBONE対応可否を確認
kubectl exec -n sidecar-namespace deployment/my-app -c istio-proxy -- pilot-agent request GET /debug/config_dump | grep ENABLE_HBONE
# 2. HBONEが無効な場合、サイドカーを再起動して最新設定を反映
kubectl rollout restart deployment -n sidecar-namespace
# 3. それでも問題が続く場合は、当該ネームスペースもambientモードへ移行
kubectl label namespace sidecar-namespace istio-injection-
kubectl label namespace sidecar-namespace istio.io/dataplane-mode=ambient
kubectl rollout restart deployment -n sidecar-namespace
事例4: istiod障害時のambientメッシュへの影響
状況: istiod Podがすべて異常になり、証明書の更新が停止した。
原因: istiodのリソース不足、etcd接続の問題、またはWebhook設定の誤り。
復旧手順:
# 1. istiodの状態確認
kubectl get pods -n istio-system -l app=istiod
kubectl logs -n istio-system -l app=istiod --tail=200
# 2. istiodの再起動
kubectl rollout restart deployment istiod -n istio-system
# 3. 証明書の更新状態を確認
istioctl proxy-status
# 参考: istiodがダウンしても既存のmTLS接続は証明書の有効期限まで維持される
# デフォルトの証明書TTLは24時間なので、istiodは24時間以内に復旧する必要がある
# 予防措置: istiodのHA構成
helm upgrade istiod istio/istiod -n istio-system \
--set pilot.replicaCount=3 \
--set pilot.resources.requests.memory=512Mi \
--set pilot.resources.requests.cpu=500m
参考資料
- Istio Ambient Mesh 公式ドキュメント - Istioプロジェクト公式のAmbient Mesh概要とアーキテクチャの説明
- Istio Ambient Data Plane アーキテクチャ - ztunnelとwaypoint proxyのデータプレーンアーキテクチャの詳細ドキュメント
- Sidecar or Ambient? - Istio公式の比較ガイド - サイドカーモードとambientモードの公式比較分析
- Istio Ambient Mesh Beta 発表 (v1.22) - AmbientモードがBetaに到達した公式発表ブログ
- Rustベースztunnelの紹介 - Istio公式ブログ - ztunnelのRustベース実装に関する技術的な詳細
- Traffic in Ambient Mesh: Ztunnel, eBPF, Waypoint Proxies - Solo.io - ztunnel、eBPF、waypoint proxy間のトラフィックフロー分析
- Network Cost Comparison: Sidecar vs Ambient - Tetrate - サイドカーとambientモードのネットワークコストの比較分析
- サイドカーからAmbient Meshへの移行ガイド - サイドカーからambientモードへの移行ガイド
- サイドカーからAmbientへのゼロダウンタイム移行 - Solo.io - 無停止での移行戦略
- Istio Ambient L7 Flow Analysis - Jimmy Song - L7トラフィック管理におけるztunnelからwaypoint proxyへのフローの分析