Ambient 資料平面

在 Ambient 模式中，工作負載可以分為 3 類

網格外 (Out of Mesh)：未啟用任何網格功能的標準 Pod。Istio 和 Ambient 資料平面未啟用。
網格內 (In Mesh)：包含在 Ambient ztunnel 攔截流量的 Pod。在此模式下，可以對 Pod 流量強制執行 L4 策略。可以設定 istio.io/dataplane-mode=ambient 標籤來啟用此模式。請參閱標籤以取得更多詳細資訊。
網格內，已啟用航點 (Waypoint)：在網格內 且已部署航點 Proxy 的 Pod。在此模式下，可以對 Pod 流量強制執行 L7 策略。可以設定 istio.io/use-waypoint 標籤來啟用此模式。請參閱標籤以取得更多詳細資訊。

根據工作負載所屬的類別，流量路徑會有所不同。

在網格路由中

對外 (Outbound)

當 Ambient 網格中的 Pod 發出對外請求時，它將被透明地重新導向到節點本機 ztunnel，它將決定轉發請求的位置和方式。一般來說，流量路由的行為就像 Kubernetes 的預設流量路由；對 Service 的請求將傳送到 Service 內的端點，而直接對 Pod IP 的請求將直接傳送到該 IP。

但是，根據目的地的功能，會發生不同的行為。如果目的地也新增到網格中，或以其他方式具有 Istio Proxy 功能（例如 Sidecar），則該請求將升級為加密的 HBONE 通道。如果目的地有航點 Proxy，除了升級為 HBONE 之外，該請求還會轉發到該航點以強制執行 L7 策略。

請注意，在請求 Service 的情況下，如果該服務有航點，則請求將傳送到其航點，以將 L7 策略應用於流量。同樣地，在請求 Pod IP 的情況下，如果該 Pod有航點，則請求將傳送到其航點，以將 L7 策略應用於流量。由於可以變更與 Deployment 中 Pod 相關聯的標籤，因此技術上可能會有某些 Pod 使用航點，而其他 Pod 則不使用。一般建議使用者避免這種進階使用案例。

對內 (Inbound)

當 Ambient 網格中的 Pod 接收到對內請求時，它將被透明地重新導向到節點本機 ztunnel。當 ztunnel 接收到請求時，它將套用授權策略，並且只有在請求通過這些檢查時才會轉發請求。

Pod 可以接收 HBONE 流量或純文字流量。依預設，ztunnel 將接受兩者。來自網格外來源的請求在評估授權策略時將沒有同儕身分，使用者可以設定需要身分（任何身分或特定身分）的策略，以封鎖所有純文字流量。

當目的地啟用航點時，如果來源位於 Ambient 網格中，則來源的 ztunnel 可確保請求將通過航點，並在該處強制執行策略。但是，網格外的工作負載不了解任何關於航點 Proxy 的資訊，因此即使目的地啟用航點，它也會將請求直接傳送到目的地，而不會通過任何航點 Proxy。目前，來自 Sidecar 和閘道的流量也不會通過任何航點 Proxy，並且在未來版本中將會知道航點 Proxy。

資料平面詳細資訊

身分

Ambient 網格中工作負載之間的所有對內和對外 L4 TCP 流量都由資料平面透過 mTLS 使用 HBONE、ztunnel 和 x509 憑證來保護。

根據 mTLS 的強制執行，來源和目的地必須具有唯一的 x509 身分，並且這些身分必須用於建立該連線的加密通道。

這需要 ztunnel 代表已 Proxy 的工作負載管理多個不同的工作負載憑證 - 每個節點本機 Pod 的每個唯一身分（服務帳戶）一個。ztunnel 自己的身分絕不用於工作負載之間的 mTLS 連線。

當提取憑證時，ztunnel 將使用自己的身分驗證 CA，但會請求另一個工作負載的身分。至關重要的是，CA 必須強制 ztunnel 有權限請求該身分。會拒絕請求未在節點上執行之身分的請求。這對於確保受損的節點不會損害整個網格至關重要。

此 CA 強制執行由 Istio 的 CA 使用 Kubernetes 服務帳戶 JWT 權杖來完成，該權杖會編碼 Pod 資訊。對於與 ztunnel 整合的任何替代 CA，此強制執行也是一項要求。

ztunnel 將請求節點上所有身分的憑證。它會根據收到的控制平面設定來判斷這一點。當在節點上發現新的身分時，為了最佳化，它會以低優先順序排隊等待提取。但是，如果請求需要尚未提取的特定身分，則會立即請求該身分。

ztunnel 還會處理這些憑證在即將到期時的輪換。

遙測

ztunnel 會發出完整的 Istio 標準 TCP 指標集。

用於第 4 層流量的資料平面範例

以下圖示描繪了之間的 L4 Ambient 資料平面。

Basic ztunnel L4-only datapath — 基本的 ztunnel 僅 L4 資料路徑

圖中顯示了多個工作負載被添加到環境網格中，這些工作負載在 Kubernetes 集群的節點 W1 和 W2 上運行。每個節點上都有一個 ztunnel 代理的單一實例。在這個情境下，應用程式用戶端 Pod C1、C2 和 C3 需要存取由 Pod S1 提供的服務。沒有對進階 L7 功能（例如 L7 流量路由或 L7 流量管理）的需求，因此 L4 資料平面足以取得 mTLS 和 L4 策略強制執行，因此不需要航點代理。

圖中顯示，在節點 W1 上運行的 Pod C1 和 C2，與在節點 W2 上運行的 Pod S1 連接。

C1 和 C2 的 TCP 流量透過 ztunnel 建立的 HBONE 連接進行安全隧道傳輸。相互 TLS (mTLS) 用於加密以及隧道傳輸流量的相互身份驗證。 SPIFFE 身份用於識別連線上每一端的工作負載。關於隧道協定和流量重新導向機制的更多詳細資訊，請參閱 HBONE 和 ztunnel 流量重新導向的指南。

請注意，本地流量（圖中顯示從 Pod C3 到工作節點 W2 上的目標 Pod S1）也會經過本地 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

下圖顯示了 ztunnel 和航點之間的資料路徑，如果為 L7 策略強制執行配置了航點。在此，ztunnel 使用 HBONE 隧道將流量發送到航點代理以進行 L7 處理。處理後，航點透過第二個 HBONE 隧道將流量發送到託管所選服務目標 Pod 的節點上的 ztunnel。一般來說，航點代理可能位於或不位於與來源或目標 Pod 相同的節點上。

Ztunnel datapath via an interim waypoint — 透過中間航點的 Ztunnel 資料路徑