アンビエントデータプレーン

アンビエントモードにおいて、ワークロードは3つのカテゴリに分類されます。

メッシュ外：メッシュ機能が有効になっていない標準的なPod。Istioとアンビエントデータプレーンは無効です。
メッシュ内：アンビエントデータプレーンに含まれ、ztunnelによってレイヤー4レベルでトラフィックがインターセプトされるPod。このモードでは、Podトラフィックに対してL4ポリシーを適用できます。このモードは、istio.io/dataplane-mode=ambientラベルを設定することで有効にできます。詳細についてはラベルを参照してください。
メッシュ内、Waypoint有効：メッシュ内であり、WaypointプロキシがデプロイされているPod。このモードでは、Podトラフィックに対してL7ポリシーを適用できます。このモードは、istio.io/use-waypointラベルを設定することで有効にできます。詳細についてはラベルを参照してください。

ワークロードがどのカテゴリに属するかに応じて、トラフィックパスが異なります。

メッシュ内ルーティング

アウトバウンド

アンビエントメッシュ内のPodがアウトバウンドリクエストを行う場合、透過的にリダイレクトされ、ノードローカルのztunnelに送られます。ztunnelはリクエストの転送先と方法を決定します。一般的に、トラフィックルーティングはKubernetesのデフォルトトラフィックルーティングと同様に動作します。ServiceへのリクエストはService内のエンドポイントに送信され、Pod IPへの直接リクエストはそのIPに直接送信されます。

ただし、宛先の機能によっては、異なる動作が発生します。宛先もメッシュに追加されている場合、またはIstioプロキシ機能（サイドカーなど）を備えている場合、リクエストは暗号化されたHBONEトンネルにアップグレードされます。宛先にWaypointプロキシがある場合、HBONEにアップグレードされることに加えて、リクエストはL7ポリシー適用のためそのWaypointに転送されます。

Serviceへのリクエストの場合、サービスにWaypointがある場合、トラフィックにL7ポリシーを適用するために、リクエストはそのWaypointに送信されます。同様に、Pod IPへのリクエストの場合、PodにWaypointがある場合、トラフィックにL7ポリシーを適用するために、リクエストはそのWaypointに送信されます。Deployment内のPodに関連付けられたラベルを変えることができるため、一部のPodはWaypointを使用し、他のPodは使用しないということが技術的に可能です。一般的に、ユーザーはこの高度なユースケースを避けることをお勧めします。

インバウンド

アンビエントメッシュ内のPodがインバウンドリクエストを受信した場合、透過的にリダイレクトされ、ノードローカルのztunnelに送られます。ztunnelはリクエストを受け取ると、認可ポリシーを適用し、リクエストがこれらのチェックに合格した場合のみリクエストを転送します。

PodはHBONEトラフィックまたはプレーンテキストトラフィックを受信できます。デフォルトでは、どちらもztunnelで受け入れられます。メッシュ外のソースからのリクエストには、認可ポリシーの評価時にピアアイデンティティがありません。ユーザーは、すべてのプレーンテキストトラフィックをブロックするために、アイデンティティ（任意のアイデンティティ、または特定のアイデンティティ）を要求するポリシーを設定できます。

宛先でWaypointが有効になっている場合、ソースがアンビエントメッシュ内にある場合、ソースのztunnelは、リクエストがポリシーが適用されるWaypointを通過することを保証します。ただし、メッシュ外のワークロードはWaypointプロキシについて何も知らないため、宛先がWaypoint有効であっても、Waypointプロキシを通過せずに宛先に直接リクエストを送信します。現在、サイドカーとゲートウェイからのトラフィックもWaypointプロキシを通過しません。これらは今後のリリースでWaypointプロキシを認識するようになります。

データプレーンの詳細

アイデンティティ

アンビエントメッシュ内のワークロード間のすべてのインバウンドおよびアウトバウンドL4 TCPトラフィックは、HBONE、ztunnel、およびx509証明書を使用して、データプレーンによって保護されます。

mTLSによって強制されるように、送信元と宛先は一意のx509アイデンティティを持つ必要があり、それらのアイデンティティを使用してその接続の暗号化チャネルを確立する必要があります。

これには、ztunnelがプロキシされたワークロードに代わって、複数の異なるワークロード証明書を管理する必要があります。ノードローカルのPodごとに一意のアイデンティティ（サービスアカウント）ごとに1つずつです。ワークロード間のmTLS接続には、ztunnel自身のアイデンティティは決して使用されません。

証明書を取得する場合、ztunnelは独自のアイデンティティでCAに対して認証しますが、別のワークロードのアイデンティティを要求します。重要なのは、CAがztunnelがそのアイデンティティを要求する権限を持っていることを強制することです。ノードで実行されていないアイデンティティの要求は拒否されます。これは、侵害されたノードがメッシュ全体を侵害しないようにするために重要です。

このCAの強制は、Pod情報をエンコードするKubernetesサービスアカウントJWTトークンを使用して、IstioのCAによって行われます。この強制は、ztunnelと統合する代替CAにも必要です。

Ztunnelは、ノード上のすべてのアイデンティティの証明書を要求します。これは、受信するコントロールプレーン構成に基づいて決定されます。ノードで新しいアイデンティティが検出されると、最適化として低優先度でフェッチキューに配置されます。ただし、まだフェッチされていない特定のアイデンティティをリクエストが必要な場合は、すぐにリクエストされます。

さらに、Ztunnelは有効期限が近づいているこれらの証明書のローテーションを処理します。

テレメトリ

Ztunnelは、Istio標準TCPメトリクスの完全なセットを出力します。

レイヤー4トラフィックのデータプレーン例

アンビエントデータプレーン間のL4は、次の図に示されています。

Basic ztunnel L4-only datapath — 基本的なztunnel L4のみのデータパス

図は、KubernetesクラスタのノードW1とW2上で実行されている、アンビエントメッシュに追加された複数のワークロードを示しています。各ノードには、ztunnelプロキシが1つずつ存在します。このシナリオでは、アプリケーションクライアントポッドC1、C2、C3は、ポッドS1によって提供されるサービスにアクセスする必要があります。L7トラフィックルーティングやL7トラフィック管理などの高度なL7機能は必要ありません。そのため、mTLSとL4ポリシーの適用を取得するには、L4データプレーンで十分です。ウェイポイントプロキシは必要ありません。

図は、ノードW1上で実行されているポッドC1とC2が、ノードW2上で実行されているポッドS1に接続していることを示しています。

C1とC2のTCPトラフィックは、ztunnelによって作成されたHBONE接続を介して安全にトンネリングされます。相互TLS（mTLS）は、暗号化と、トンネリングされるトラフィックの相互認証に使用されます。SPIFFE IDは、接続の両側のワークロードを識別するために使用されます。トンネリングプロトコルとトラフィックリダイレクトメカニズムの詳細については、HBONEとztunnelトラフィックリダイレクションに関するガイドを参照してください。

ワーカーノードW2上の宛先ポッドS1へのポッドC3からのローカルトラフィック（図に示されている）もローカルztunnelプロキシインスタンスを通過することに注意してください。これにより、ノード境界を超えるかどうかに関係なく、L4承認やL4テレメトリなどのL4トラフィック管理機能がトラフィックに対して同じように適用されます。

Waypoint有効時のメッシュ内ルーティング

Istioウェイポイントは、HBONEトラフィックのみを受け取ります。リクエストを受け取ると、ウェイポイントは、そのトラフィックがウェイポイントを使用するPodまたはService宛てであることを確認します。

トラフィックを受け入れると、ウェイポイントは、転送前にL7ポリシー（AuthorizationPolicy、RequestAuthentication、WasmPlugin、Telemetryなど）を適用します。

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

Serviceへのリクエストの場合、ウェイポイントはルーティングとロードバランシングも適用します。デフォルトでは、Serviceは単に自身にルーティングされ、そのエンドポイント間でL7ロードバランシングを実行します。これは、そのServiceのルートで上書きできます。

たとえば、以下のポリシーにより、echoサービスへのリクエストがecho-v1に転送されます。

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: echo
spec:
  parentRefs:
  - group: ""
    kind: Service
    name: echo
  rules:
  - backendRefs:
    - name: echo-v1
      port: 80

次の図は、L7ポリシー適用のために1つが構成されている場合、ztunnelとウェイポイント間のデータパスを示しています。ここで、ztunnelはHBONEトンネリングを使用して、L7処理のためにトラフィックをウェイポイントプロキシに送信します。処理後、ウェイポイントは、選択されたサービス宛先ポッドをホストするノード上のztunnelに、2番目のHBONEトンネルを介してトラフィックを送信します。一般に、ウェイポイントプロキシは、ソースポッドまたは宛先ポッドと同じノード上にある場合と、そうでない場合があります。

Ztunnel datapath via an interim waypoint — 中間ウェイポイントを経由するZtunnelデータパス