功能介紹

阿里云服務網格ASM從1.18版本開始支持Ambient模式。該模式下引入了一種新的Sidecarless的數據平面形態，幫助簡化應用服務的網格接入，提供一種漸進式采用網格技術的途徑，并降低Istio網格用戶的基礎設施成本。

ASM Ambient模式支持Sidecar和Sidecarless兩種形態的數據平面架構。您可以根據應用程序的需求選擇其中之一或兩者融合使用。在ASM 1.18版本中，Sidecar代理已支持HBONE（基于HTTP的覆蓋網絡環境），因此它們可以通過零信任隧道zTunnel提供安全覆蓋層、通過Waypoint代理提供7層處理能力，支持Sidecarless模式下的應用程序相互操作。

設計理念

將數據平面分層：4層用于基礎處理，特點是低資源、高效率；7層用于高級流量處理，特點是功能豐富，但需要更多的資源。您可以根據所需功能的范圍，以漸進增量的方式使用服務網格技術。

數據面L4與L7代理的解耦模式下，一方面，將L4 Proxy能力下移到CNI組件中，L4 Proxy組件以DaemonSet的形式運行，分別運行在每個節點上。這意味著它是為一個節點上運行的所有Pod提供服務的共享基礎組件。

另一方面，L7代理不再以Sidecar模式存在，而是解耦出來，稱為Waypoint Proxy，它是為每一個Service Account創建的7層代理Pod。

4層和7層代理的配置仍然保持通過Service Mesh控制面組件來進行下發管理。通過這種解耦模式，實現了Service Mesh數據平面與應用程序之間的進一步解耦分離。

在Istio的具體實現中，可以分為以下3個部分：

• Waypoint代理：

  • L7組件完全獨立于應用程序運行，安全性更高。

  • 可以靈活選擇為指定服務、工作負載指定不同的L7代理（Waypoint代理）。

  • 通過K8s Gateway CRD定義觸發啟用。

• zTunnel：將L4處理下沉到CNI級別，來自工作負載的流量被重定向到zTunnel，然后zTunnel識別工作負載并選擇正確的證書進行處理。

• 與Sidecar模式兼容：Sidecar模式仍然是網格的一等公民，Waypoint代理可以與部署了Sidecar的工作負載進行本地通信。

不影響應用程序是使Ambient Mesh比傳統的Sidecar模式具備更少侵入性的原因之一。與采用Sidecar模式時必須將Sidecar代理注入到每個應用程序部署中相比，Ambient模式下無需以任何方式重新部署或修改現有應用程序。通過不重新部署和直接修改應用程序，可以有效地降低落地風險并簡化采用Mesh的落地曲線。

Ambient Mesh的設計是非侵入式的，并且僅對存在特定標記的命名空間并使現有應用程序成為Ambient Mesh的一部分，可以逐步采用。一旦應用程序成為Ambient Mesh的一部分，它立即獲得mTLS和L4可觀察性功能。

Ambient模式下的路由

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

• 未攔截：這是一個沒有啟用任何Mesh特性的標準Pod。

• 已攔截：這是一個通過zTunnel攔截流量的Pod。您可以通過在命名空間上設置istio.io/dataplane-mode=ambient標簽來捕獲Pod。

• Waypoint啟用：這是一個已攔截且部署了Waypoint代理的Pod。默認情況下，Waypoint代理將應用于同一命名空間中的所有Pod。還可以通過在Gateway上設置istio.io/for-service-account注釋，將其設置為僅適用于特定的服務賬戶。如果同時存在命名空間Waypoint代理和服務賬戶Waypoint代理，則服務賬戶Waypoint代理的優先級更高。

zTunnel路由

• 出站

  當一個被攔截的Pod發起出站請求時，它將被透明地重定向到zTunnel，zTunnel將確定請求的轉發位置和方式。一般情況下，流量路由的行為與Kubernetes默認的流量路由相同。對一個Service的請求將被發送到該Service內的一個端點，而直接對Pod IP的請求將直接發送到該IP。根據目標的能力，會發生不同的行為。如果目標也被攔截，或者具有Istio代理能力（例如注入了Sidecar代理或網關），請求將升級為加密的HBONE隧道。如果目標有一個Waypoint代理，除了升級為HBONE外，請求將被轉發到該Waypoint代理。

  需要注意的是，在請求一個Service時，會選擇一個特定的端點來確定是否有Waypoint代理。但是，如果有Waypoint代理，請求將被發送到Service的目標目的地，而不是選定的端點。這樣可以使Waypoint代理將面向服務的策略應用于流量。在Service同時具有啟用Waypoint和未啟用Waypoint的端點的罕見情況下，一些請求將被發送到Waypoint，而對同一服務的其他請求則不會。

• 入站

  當一個被攔截的Pod接收到入站請求時，它將被透明地重定向到zTunnel。當zTunnel接收到請求時，它將應用授權策略，并只有在請求符合策略時才轉發請求。一個Pod可以接收HBONE流量或明文流量。默認情況下，zTunnel將接受這兩種流量。因為在評估授權策略時，明文請求沒有對等身份，您可以設置一個策略要求一個身份（任意身份或特定身份），以阻止所有明文流量。

  當目標啟用了Waypoint代理時，所有請求必須經過Waypoint代理來執行策略。zTunnel將確保這一點，但存在一個特殊情況：良好行為的HBONE客戶端（例如另一個zTunnel或Istio Sidecar代理）會知道將請求發送到waypoint，但其他客戶端（例如網格之外的工作負載）可能對waypoint代理一無所知，直接發送請求。當發送這些直接調用時，zTunnel會將請求繞圈（hairpin）到它的waypoint，以確保策略得到正確執行。

Waypoint路由

Waypoint代理只接收HBONE請求。在接收到請求后，Waypoint代理將確保請求的目標是其管理的Pod或包含其管理的Pod的Service。

對于任何類型的請求，在轉發之前，Waypoint代理將執行策略（例如授權策略、WASM插件、遙測等）。

對于直接請求到Pod的情況，策略應用后，請求將直接轉發。

對于針對Service的請求，Waypoint代理還將應用路由和負載均衡。默認情況下，Service將簡單地路由到自身，并在其端點間進行負載均衡。您可以通過為該Service設置路由來覆蓋默認行為。

與Sidecar模式的差異點

• 4層與7層處理的解耦，引入基于Rust的zTunnel作為基礎的4層處理模塊，適合做高性能、低利用率的網絡代理能力。

• Waypoint代理面向目標服務進行定義，僅需包含非常有限的動態集群、端點和路由相關的詳細信息，而無需將所有潛在連接到其運行的Kubernetes集群中的任何服務的詳細信息都包含內。這有效地消除了對Waypoint代理支持Sidecar資源的需求，也避免您手動配置Sidecar資源。

Ambient Sidecarless模式的優勢

• 網格代理與應用程序解耦，獨立運行，當代理更新或重啟時，不需要對應用程序進行重啟。

• 擴大了對應用程序的支持，包括支持Kubernetes Jobs等。

• 消除了Sidecar模式下對應用程序的要求，包括服務器發送優先協議等。

• 更好地逐步采用網格技術的接入，例如從安全覆蓋層開始，使用加密身份的mTLS、簡單的第4層授權策略和可觀測功能。

• 在沒有任何L7處理的情況下，安全覆蓋層顯著地減少了CVE和其他補丁的攻擊面和更新數據平面的頻率。

• 獨立于工作負載擴展服務網格數據平面，從而降低基礎設施的成本。