本文介紹Ambient模式的概念及相關功能。
功能介紹
阿里雲Service MeshASM從1.18版本開始支援Ambient模式。該模式下引入了一種新的Sidecarless的資料平面形態，協助簡化應用服務的網格接入，提供一種漸進式採用網格技術的途徑，並降低Istio網格使用者的基礎設施成本。
ASM Ambient模式支援Sidecar和Sidecarless兩種形態的資料平面架構。您可以根據應用程式的需求選擇其中之一或兩者融合使用。在ASM 1.18版本中，Sidecar代理已支援HBONE（基於HTTP的覆蓋網路環境），因此它們可以通過零信任隧道zTunnel提供保護傘、通過Waypoint代理提供7層處理能力，支援Sidecarless模式下的應用程式相互操作。
設計理念
將資料平面分層：4層用於基礎處理，特點是低資源、高效率；7層用於進階流量處理，特點是功能豐富，但需要更多的資源。您可以根據所需功能的範圍，以漸進增量的方式使用服務網格技術。
層級 | 主要功能 |
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和其他補丁的攻擊面和更新資料平面的頻率。
獨立於工作負載擴充服務網格資料平面，從而降低基礎設施的成本。