Alibaba Cloud Service Mesh (ASM) は、Sidecar モードとAmbient モードという 2 種類のデータプレーンモードをサポートしています。どちらのモードも、トラフィック管理、セキュリティ、可観測性において Istio の全機能を提供しますが、アーキテクチャ、リソースオーバーヘッド、運用モデルが異なります。
Sidecar モード
Sidecar モードでは、すべての Pod に Envoy プロキシのサイドカーが注入され、インバウンドおよびアウトバウンドのすべてのトラフィックをインターセプトします。
ASM は初回リリース時から Sidecar モードをサポートしており、複数回の反復と大規模な本番環境での利用を経て、最も成熟度が高く安定したオプションとなっています。
トラフィックパス
次の図は、Sidecar モードにおける典型的なトラフィックパスを示しています。
Ambient モード
Istio コミュニティは 2022 年に Ambient モードを導入し、Sidecar モードに内在する制限に対応しました。各 Pod にプロキシを注入する代わりに、Ambient モードではレイヤー 4 (L4) とレイヤー 7 (L7) の処理を、それぞれ独立した 2 つのコンポーネントに分離します。
-
ztunnel：Rust 製の L3/L4 プロキシで、DaemonSet としてデプロイされます。同一ノード上の Pod は単一の ztunnel インスタンスを共有します。このコンポーネントは、それらの Pod に出入りするすべてのトラフィックについて、mTLS 暗号化、本人確認、L4 権限付与、L4 可観測性を処理します。
-
Waypoint プロキシ：Envoy ベースの L7 プロキシで、Deployment としてデプロイされ、アプリケーションポッドとは完全に独立しています。Waypoint プロキシのアップグレードまたはインストールには、アプリケーションポッドへの変更は不要です。
ASM 1.25 以降、Ambient モードはシングルクラスターシナリオにおいて本番環境対応となっています。
Ambient モードの開始手順
-
名前空間に ambient を有効にするラベルを追加すると、即座に mTLS および L4 可観測性が有効になります。サイドカーの注入や Pod の再起動は不要です。
-
HTTP ベースのルーティング、L7 権限付与、分散トレーシングなどの L7 機能を利用する場合は、特定のサービス、Pod、または名前空間全体に対して Waypoint プロキシをデプロイします。
複数のサービスまたは Pod が同じ Waypoint プロキシを共有できます。これらのサービスへのすべてのリクエストは、アプリケーションに到達する前に Waypoint を経由します。
トラフィックパス
次の図は、Ambient モードにおけるトラフィックパスを示しています。
機能比較
|
機能 |
Sidecar モード |
Ambient モード |
|
トラフィック管理 |
Istio の全機能をサポート |
Istio の全機能をサポート（Waypoint が必要） |
|
セキュリティ |
Istio の全機能をサポート |
Istio の全機能をサポート：デフォルトで mTLS および L4 セキュリティを提供；L7 権限付与には Waypoint が必要 |
|
可観測性 |
Istio の全機能をサポート |
Istio の全機能をサポート：デフォルトで L4 可観測性を提供；L7 可観測性には Waypoint が必要 |
|
導入 |
名前空間に自動注入ラベルを追加し、すべての Pod を再起動 |
名前空間にラベルを追加するだけで、Pod の再起動は不要 |
|
アップグレード |
インプレースおよびカナリアアップグレードが可能；新しいサイドカーのバージョンを注入するには、すべての Pod を再起動する必要があります |
インプレースアップグレードが可能；データプレーンコンポーネントはコントロールプレーンとともにアップグレードされ、Pod の再起動は不要 |
|
ライフサイクル管理 |
アプリケーション開発者がプロキシを管理 |
プラットフォーム管理者がプロキシを管理；アプリケーション開発者からは透明 |
|
リソース使用率 |
各 Pod が L7 プロキシを実行するため、高使用率の維持が困難 |
Waypoint プロキシは独立してスケーリング可能；名前空間またはクラスター全体で単一の Waypoint を共有可能 |
|
平均リソースコスト |
高 |
低 |
|
平均レイテンシ（Istio コミュニティのデータ） |
0.63 ms ～ 0.88 ms |
Waypoint なし：0.16 ms ～ 0.20 ms；Waypoint あり：0.40 ms ～ 0.50 ms |
|
L7 解析 |
2 回（クライアントサイドカー + サーバーサイドカー） |
Waypoint なし：0；Waypoint あり：1 |
|
大規模環境への対応 |
各サイドカーの構成範囲をファインチューニングして構成ボリュームを削減する必要がある |
チューニング不要；必要な構成のみがデフォルトで配信される |
|
サーバーファーストプロトコルのサポート |
明示的な構成が必要 |
デフォルトでサポート |
|
Kubernetes Job のサポート |
サイドカーが Pod のライフサイクルにバインドされるため、複雑 |
透過的なサポート |
|
セキュリティモデル |
最強：各ワークロードが独自のキーを保持 |
強固：各 ztunnel は自身のノード上のワークロードのキーのみを保持 |
|
侵害された Pod がメッシュキーにアクセス可能か？ |
はい |
いいえ |
-
Ambient モードでは L4/L7 が分離されているため、L7 機能が不要な場合は L7 処理のオーバーヘッドを完全に回避できます。
-
同一メッシュ内で Sidecar モードと Ambient モードを混在させることは、現時点で本番環境対応ではありません。異なるモードの Pod 間で通信することはできません。
-
Ambient モードは現時点でマルチクラスター管理をサポートしていません。
Ambient モードの L4 および L7 機能
L7 トラフィック処理は L4 よりも大幅に高いオーバーヘッドを伴います。サービスが L4 機能のみを必要とする場合、そのサービスに対して Waypoint プロキシをスキップすることで、リソース消費を削減しパフォーマンスを向上できます。
|
ディメンション |
L4 機能（ztunnel） |
L7 機能（Waypoint） |
|
セキュリティ |
mTLS 暗号化、ServiceAccount ベースの権限付与、IP ベースの権限付与 |
HTTP メタデータベースの権限付与（メソッド、パス）、JWT 認証、JWT ベースの権限付与、OPA ベースの権限付与 |
|
可観測性 |
送信元/送信先 IP およびポート、送受信バイト数 |
トレーシング分析、HTTP リクエストの完全記録（メソッド、パス、ホスト、状態コード） |
|
ルーティング |
TCP 接続レベルの負荷分散、サーキットブレーカー、レート制限、タイムアウト、リトライ |
HTTP リクエストレベルの負荷分散、サーキットブレーカー、レート制限、タイムアウト、リトライ、障害注入、トラフィックミラーリング |
|
拡張性 |
該当なし |
WasmPlugin |