:概要

機能の説明

Service Mesh (ASM) インスタンス（バージョン 1.18 以降）では、Ambient Mesh モードがサポートされています。Ambient Mesh は、サイドカーレス データプレーンを導入することで、アプリケーションとサービスメッシュの統合を簡素化し、ユーザーにサービスメッシュを段階的に使用する方法を提供し、Istio ユーザーのインフラストラクチャ コストを削減します。

Ambient Mesh は、サイドカーありとなしの両方のデータプレーンをサポートしています。アプリケーションの要件に基づいて、一方または両方を使用できます。バージョン 1.18 の ASM インスタンスでは、サイドカープロキシは HTTP-Based Overlay Network Environment (HBONE) をサポートしています。そのため、このようなサイドカープロキシは、ゼロトラストトンネル (ztunnel) またはウェイポイントプロキシを使用して、サイドカーレス アプリケーションと相互運用できます。場合によっては、ztunnel とウェイポイントプロキシが一緒に使用されます。ztunnel はセキュアなオーバーレイ層を提供し、ウェイポイントプロキシはレイヤー 7 処理機能を提供します。

設計理念

Ambient Mesh は、データプレーンをレイヤー 4 とレイヤー 7 の 2 つの異なるレイヤーに分割します。基本的な処理はレイヤー 4 で実行され、効率が高く、リソース消費が少ないという特徴があります。トラフィックを処理するための高度な機能はレイヤー 7 で提供され、より多くのリソースを必要とします。必要な機能に応じて、サービスメッシュ技術を段階的に採用できます。

Ambient Mesh モードでは、レイヤー 4 プロキシ (ztunnel とも呼ばれます) とレイヤー 7 プロキシ (ウェイポイントプロキシとも呼ばれます) は分離されています。レイヤー 4 プロキシの機能は、Container Network Interface (CNI) プラグインを使用して実装されます。レイヤー 4 プロキシは、すべてのノードで DaemonSet として実行されます。これは、レイヤー 4 プロキシが、同じノードで実行されているすべてのポッドにサービスを提供する共有コンポーネントであることを意味します。

レイヤー 7 プロキシは、サイドカーとしてではなく、レイヤー 7 処理用のサービスアカウントごとのポッドとしてデプロイされます。

レイヤー 4 プロキシとレイヤー 7 プロキシの構成は、引き続き ASM のコントロールプレーンのコンポーネントによって管理されます。レイヤー 4 プロキシとレイヤー 7 プロキシの分離により、アプリケーションと ASM のデータプレーンをさらに分離することができます。

Istio での Ambient Mesh の実装には、次の 3 つの部分が含まれます。

• ウェイポイントプロキシ:

  • アプリケーションから分離されたレイヤー 7 コンポーネントであり、セキュリティを強化します。

  • 特定のウェイポイントプロキシは、各 ID (Kubernetes のサービスアカウント) に提供されます。これにより、マルチテナント レイヤー 7 プロキシモードによってもたらされる複雑さと不安定さが回避されます。

  • ウェイポイントプロキシは、Kubernetes ゲートウェイ CustomResourceDefinition (CRD) を構成することで有効になります。

• Ztunnel: Ztunnel は、CNI プラグインを使用してレイヤー 4 処理を実装します。ワークロードからのトラフィックは、対応する ztunnel にリダイレクトされ、ztunnel はワークロードを識別し、トラフィック処理に適切な証明書を選択します。

• サイドカーとの互換性: サイドカープロキシが構成されたデータプレーンは、ユーザーがサービスメッシュを使用する際に最も広く使用されています。ウェイポイントプロキシは、サイドカープロキシがデプロイされているワークロードと通信できます。

従来のモードでは、各アプリケーションにサイドカープロキシを挿入する必要があります。ただし、Ambient Mesh モードでは、既存のアプリケーションを再デプロイまたは変更する必要はありません。そのため、Ambient Mesh は従来のモードよりも非侵襲的です。非侵襲性は、実装リスクを軽減し、Ambient Mesh の使用を簡素化するのに役立ちます。

Ambient Mesh は非侵襲的です。Ambient Mesh モードでは、アプリケーションが存在する名前空間に特定のラベルを追加することで、アプリケーションをサービスメッシュに追加できます。Ambient Mesh モードでアプリケーションがサービスメッシュに追加されると、相互トランスポート層セキュリティ (mTLS) メソッドとレイヤー 4 によって提供される可観測性機能がアプリケーションで使用可能になります。

Ambient Mesh モードでのルーティング

Ambient Mesh モードでは、ワークロードは次の 3 つのカテゴリに分類できます。

• キャプチャされていない: メッシュ機能が有効になっていない標準のポッド。

• キャプチャされた: トラフィックが ztunnel によってインターセプトされるポッド。istio.io/dataplane-mode=ambient ラベルを名前空間に追加することで、ポッドをキャプチャできます。

• ウェイポイント対応: トラフィックが ztunnel によってインターセプトされ、ウェイポイントプロキシがデプロイされているポッド。デフォルトでは、ウェイポイントプロキシは同じ名前空間内のすべてのポッドで共有されます。Kubernetes ゲートウェイ CRD に istio.io/for-service-account アノテーションを追加することで、ウェイポイントプロキシを特定のサービスアカウント専用にすることもできます。名前空間固有のウェイポイントプロキシとサービスアカウント固有のウェイポイントプロキシの両方が構成されている場合、サービスアカウント固有のウェイポイントプロキシが優先されます。

Ztunnel ルーティング

• アウトバウンド

  キャプチャされたポッド内のアプリケーションがアウトバウンドリクエストを開始すると、リクエストはポッドが実行されているノードの ztunnel に透過的にリダイレクトされます。次に、ztunnel はリクエストを転送する方法とリクエストの宛先を選択します。一般的に、トラフィックルーティングの動作は、Kubernetes のデフォルトのトラフィックルーティングと同じです。Kubernetes のサービスへのリクエストの場合、リクエストはサービス内のエンドポイントに送信されます。ただし、ポッド IP アドレスへのリクエストは、その IP アドレスに直接送信されます。リクエストのルーティング動作は、リクエストの宛先の機能によって異なります。リクエストの宛先もキャプチャされているか、Istio プロキシ機能 (たとえば、サイドカープロキシまたは Istio ゲートウェイがデプロイされている) を備えている場合、リクエストは暗号化された HBONE トンネルを使用してルーティングされます。宛先にウェイポイントプロキシがある場合、リクエストは暗号化された HBONE トンネルを使用してルーティングされるだけでなく、そのウェイポイントプロキシに転送されます。

  サービスへのリクエストが行われた場合、リクエストが開始されたポッドの ztunnel は、ポッドに対してウェイポイントプロキシが構成されているかどうかを確認するためにポッドを選択します。選択したポッドに対してウェイポイントプロキシが構成されている場合、リクエストはウェイポイントプロキシに送信されます。次に、ウェイポイントプロキシはリクエストを宛先に送信します。これにより、ウェイポイントプロキシはトラフィックにサービス指向のポリシーを適用できます。サービスの場合、一部のポッドに対してウェイポイントプロキシが有効になっているが、すべてのポッドに対して有効になっていない場合、一部のリクエストはウェイポイントプロキシに送信されますが、同じサービスへの他のリクエストは送信されません。

• インバウンド

  キャプチャされたポッドがインバウンドリクエストを受信すると、リクエストはポッドの ztunnel に透過的に転送されます。ztunnel がリクエストを受信すると、ztunnel は承認ポリシーを適用し、リクエストがポリシーに準拠している場合にのみリクエストを転送します。ポッドは、HBONE 準拠のトラフィックまたはプレーンテキストトラフィックを受信できます。デフォルトでは、ztunnel はこれら 2 種類のトラフィックを受け入れます。プレーンテキストリクエストは、承認ポリシーが評価されるときにピア ID を持たないため、ID (任意の ID または特定の ID) を必要とするポリシーを構成して、すべてのプレーンテキストトラフィックをブロックできます。

  宛先に対してウェイポイントプロキシが有効になっている場合、すべてのリクエストは、ポリシーが実行されるウェイポイントプロキシを通過する必要があります。対応する ztunnel は、これが発生することを保証します。ただし、次のエッジケースが存在します。別の ztunnel や Istio サイドカーなどの動作の良い HBONE クライアントは、リクエストをウェイポイントプロキシに送信する必要があることを認識していますが、メッシュ外のワークロードなどの他のクライアントはウェイポイントプロキシについて何も知らず、リクエストを宛先ポッドに直接送信します。このような直接呼び出しの場合、ztunnel は受信したリクエストを独自のウェイポイントプロキシに送信して、ポリシーが正しく実行されるようにします。

ウェイポイントルーティング

ウェイポイントプロキシは、HBONE リクエストのみを受信します。リクエストを受信すると、ウェイポイントプロキシは、リクエストの宛先が管理対象のポッド、または管理対象のポッドを含むサービスであることを確認します。

どちらの種類のリクエストについても、ウェイポイントプロキシは、AuthorizationPolicy、WasmPlugin、Telemetry などのポリシーを適用してから、リクエストを転送します。

ポッドへの直接リクエストの場合、リクエストはポリシーが適用された後に直接転送されます。

サービスへのリクエストの場合、ウェイポイントプロキシはルーティングと負荷分散も適用します。デフォルトでは、サービスはトラフィックを自身にルーティングし、エンドポイント間で負荷分散を実行します。このサービスのルートを構成することで、デフォルトの動作をオーバーライドできます。

サイドカーアーキテクチャとの違い

• Ambient Mesh モードでは、レイヤー 4 とレイヤー 7 の処理機能が分離されています。Rust ベースの ztunnel は、レイヤー 4 処理のために導入されています。Ztunnel は、リソース消費が少ない高性能ネットワークプロキシとして機能できます。

• ウェイポイントプロキシは宛先指向です。ウェイポイントプロキシの構成には、ウェイポイントプロキシが実行されているクラスター内のすべてのサービスの詳細ではなく、ウェイポイントプロキシが接続する必要がある限られた動的クラスター、エンドポイント、およびルートに関する情報のみを含める必要があります。これにより、ウェイポイントプロキシのサイドカーリソースをサポートする必要が効果的に排除されます。サイドカーリソースを手動で構成する必要はありません。

Ambient Mesh のメリット

• メッシュプロキシはアプリケーションとは独立して実行されます。プロキシが更新または再起動されたときに、アプリケーションを再起動する必要はありません。

• これにより、Kubernetes ジョブのサポートなど、アプリケーションのサポートが拡張されます。

• Ambient Mesh は、サーバーファーストプロトコルの制限など、サイドカーアーキテクチャにおけるアプリケーションの要件を排除します。

• Ambient Mesh モードでは、メッシュ技術を段階的に採用できます。たとえば、初期段階でセキュアなオーバーレイ層を使用して、mTLS、シンプルなレイヤー 4 承認ポリシー、および可観測性機能を実装できます。

• レイヤー 7 処理が不要な場合、セキュアなオーバーレイ層は、攻撃対象領域と、一般的な脆弱性と暴露 (CVE) およびその他の修正プログラムのデータプレーンを更新する頻度を大幅に削減できます。

• Ambient Mesh を使用すると、ワークロードとは独立してデータプレーンをスケーリングできるため、インフラストラクチャ コストを削減できます。