摘要：Ambient Mesh以一種更符合大規模落地要求的形態出現，克服了大多數Sidecar模式的固有缺陷，讓使用者無需再感知網格相關元件，真正將網格下沉為基礎設施。
本文分享自華為雲社群《華為云云原生團隊：Istio資料面新模式 Ambient Mesh技術解析》，作者： 雲容器大未來。
如果說在以Kubernetes為基礎構建起的雲原生世界裡，哪種設計模式最為經典，Sidecar模式無疑是其中最有力的競爭者。當需要為應用提供與自身邏輯無關的輔助功能時，在應用Pod內注入對應功能的Sidecar顯然是最Kubernetes Native的方式，而Istio則是這種模式的代表。
Istio專案的願景是以儘量透明的方式，解決微服務場景下，服務間的連線、安全以及可觀測性問題。主要實現手段則是透過在應用旁部署一個Proxy，在Kubernetes場景下則為應用Pod注入Sidecar，攔截應用流量至Sidecar。Sidecar根據從Istio控制面獲取的使用者配置對應用流量進行處理，以一種對應用程式碼幾乎無侵入的方式實現了服務治理。
雖然Istio並不侷限於僅支援Kubernetes平臺，但是Istio的設計理念與Kubernetes的Sidecar模式有著天然的親和性。基於Sidecar模式，Istio能夠實現在Kubernetes平臺上的快速開發、部署、驗證。同時，在功能層面，Isito將服務治理功能從應用程式碼中剝離，作為基礎設施下沉至Sidecar，抽象出了事實上的雲原生應用網路層，極大地減輕了應用開發者的心智負擔，這部分能力剛好也是Kubernetes生態一直以來缺失的。基於Istio對於Kubernetes生態的完美補充，隨著Kubernetes的大規模普及，Istio也實現了對使用者心智以及市場的快速搶佔。
雖然以Sidecar模式部署Istio資料面似乎是一個理所應當，讓人無法拒絕的選擇，但是需要強調的是，Istio完整功能的實現並不與Sidecar模式強繫結，我們還有各種各樣其他的選擇。另外，隨著對於Istio使用程度不斷加深，落地規模不斷擴大，可以發現以Sidecar模式部署Istio資料面諸多挑戰：
1. 侵入性：Istio基本實現了對應用程式碼的零侵入，但是由於Sidecar的注入需要更改Pod Spec並且對應用流量進行重定向，因此應用接入網格時需要重啟Pod，而應用容器與Sidecar容器的啟動順序不確定造成的衝突也可能導致應用中斷；
2. 生命週期繫結： Sidecar本質上是基礎設施，它和應用的生命週期往往不一致，因此升級Sidecar時也需要對應用Pod進行重啟，同樣可能導致應用中斷，而對於Job類應用，Sidecar的存在則會導致Pod無法被及時清理；
3. 資源利用率低：Sidecar為單個應用Pod獨佔，應用的流量存在波峰波谷，而一般情況下Sidecar的記憶體佔用與叢集規模（Service數目，Pod數目）強相關，因此需要按照極端情況預留資源，導致叢集整體的資源利用率低。同時由於需要為每個Pod注入Sidecar，隨著叢集規模的不斷擴大，Sidecar佔用的資源總量也會線性上漲。
針對Sidecar部署模式的缺陷，Google和Solo.io聯合推出了一種新的Sidecar-less部署模式 --- Ambient Mesh。
架構介紹
Ambient Mesh架構如上圖所示，從設計的角度來看，它主要有以下兩個特點：
1. Sidecar-less：為了避免上述Sidecar模式的種種缺陷，Ambient Mesh不再為任何Pod注入Sidecar，將網格功能的實現進一步下沉到Istio自有元件中。
2. L4/L7處理分層：Ambient Mesh引入了ztunnel和waypoint兩個元件用於代替原來的Sidecar實現相關功能，與Sidecar既能處理L4，又能處理L7流量的實現方式不同，Ambient Mesh對兩者進行了區分，ztunnel只負責L4流量的處理，L7的流量則按需交由waypoint處理。
Ambient Mesh的控制面與原先Sidecar模式的Istio相比基本沒有變化，資料面的元件構成以及各個元件的作用如下：
1. istio-cni：必裝元件，以DaemonSet的形式部署。其實istio-cni並不是Ambient Mesh的新增元件，在原先的Sidecar模式中就已經存在，當時主要用於替代istio-init這個Init Container配置流量攔截規則，同時規避istio-init引發的安全問題。Ambient Mesh對它進行了擴充套件，以必裝元件的形式部署，負責配置流量轉發規則，劫持本節點中已加入Ambient Mesh的Pods的應用流量，轉發至本節點的ztunnel；
2. ztunnel: 必裝元件，以DaemonSet的形式部署。ztunnel對所在節點Pods的流量進行代理，主要負責L4流量的處理、L4的遙測以及服務間mTLS（雙向認證）的管理。最初ztunnel基於Envoy實現，但是考慮到對ztunnel功能的有意約束以及對安全性、資源佔用率的要求，社群已經用rust從零構建該元件；
3. waypoint：按需配置，以Deployment的形式部署。waypoint負責處理HTTP，故障注入等L7功能。以負載或者Namespace粒度進行部署，在Kubernetes中，即一個Service Account或者一個Namespace對應生成一個waypoint的Deployment，用於處理發往對應負載的七層流量，同時waypoint例項數可以根據流量動態伸縮。
下面以Ambient Mesh資料面實際的處理過程來展示上述各個元件在其中扮演的具體角色：
1. 與Sidecar模式類似，Ambient Mesh也能以網格、Namespace以及Pod的粒度將服務加入網格；不同的是，新加入的Pod無需重啟，更不需要注入Sidecar；
2. istio-cni監聽本節點內Pods的增刪以及進出網格的情況，動態調整轉發規則，網格內Pods發出的流量會被透明地轉發至本節點的ztunnel，直接跳過kube-proxy的處理；
3. ztunnel同樣需要對本節點Pods的增刪以及進出網格的情況進行監聽，從控制面獲取位於本節點且被網格接管的Pods的證書並進行管理；
4. 源端ztunnel對攔截的流量進行處理，根據流量的源IP找到對應Pod的證書，由此和對端建立mTLS；
5. 如果要訪問的目標服務沒有配置waypoint或者沒有配置L7相關的處理策略，則源端ztunnel直接和目的端ztunnel建立連線（如上圖黃線標註），對端的ztunnel終止mTLS，執行L4安全策略，將流量轉發到目標Pod；
6. 如果目標服務配置了waypoint（利用特殊配置的Gateway物件）以及L7的處理策略，則源端ztunnel會和對應的waypoint建立mTLS，waypoint終止mTLS後，進行L7的邏輯處理，之後再與目標Pod所在節點的ztunnel建立mTLS，最終同樣由目的端的ztunnel終止mTLS並將流量發往目標Pod。
價值分析
雖然從底層實現來看，Ambient Mesh和原有的Sidecar模式的差別巨大，但是從使用者面看，兩者在核心Istio API（VirtualService, DestinationRules等）的使用方式、實現效果都是一致的，能夠確保基本相同的使用者體驗。Ambient Mesh是Istio社群除Sidecar模式外，支援的第二種資料面模式，所以網格技術本身能為使用者帶來的價值，Ambient Mesh與先前的Sidecar模式並不二致。因此這裡只對Ambient Mesh相對於原生Sidecar模式的價值進行分析，對於網格本身的價值不再贅述。
Ambient Mesh主要是針對Istio的資料面架構進行調整，用於克服既有Sidecar模式的不足，因此它的價值產生必然是基於其架構特點。前文已經提到過Ambient Mesh的架構特點主要有“Sidecar-less”和“L4/L7處理分層”這兩點，下面就從這兩點出發進行價值分析：
1. Sidecar-less的優勢，其實可以看作Sidecar模式缺陷的對立面：
- 透明：網格功能下沉至基礎設施，不僅對應用程式碼零侵入，和應用的生命週期也完全解耦，做到真正對應用透明，允許應用與網格獨立演進；
- 最佳化資源佔用：資料面佔用的CPU、記憶體等資源不再隨著例項數線性增長，隨著資料面的例項數減少，與控制面的連線數也相應減少，極大地減輕控制面的資源與處理壓力。
2. 對於為什麼要對L4/L7進行分層處理，首先要區分兩者之間的區別。與L4相比，L7的處理更為複雜，需要佔用更多的CPU/記憶體等資源，不同型別的操作之間資源佔用也存在較大差別；同時操作越複雜暴露的攻擊面越大。另外Envoy當前並不支援對不同租戶的流量進行強隔離，“Noisy Neighbor”的問題不可避免。因此Ambient Mesh分層處理架構的優勢如下：
- 資源利用率高：ztunnel僅負責L4的處理，L4處理較為簡單且資源佔用較為固定，所以更易對ztunnel進行資源規劃，無需過量預留資源，能夠將更多的節點資源供使用者使用；waypoint更可以根據L7負載動態擴縮容，充分利用叢集中的資源碎片；
- 租戶隔離：處理複雜、安全風險高的L7處理由租戶（Service Account）各自的waypoint處理，既避免了租戶間的資源搶佔，又限制了安全問題的爆炸半徑；
- 平滑落地：允許使用者逐步接入網格，當僅需網格的L4處理能力時，完全無需考慮L7的資源佔用以及可能造成的潛在負面影響（例如：因為錯誤配置導致進入L7處理而應用並未完全遵守L7協議，導致服務中斷），之後在適當時刻按需開啟相關功能即可。
當然Ambient Mesh作為Istio全新的資料面架構，在社群中依然以實驗特性的形式存在，仍然有許多問題亟待解決，例如：
1. 效能：尤其是針對L7的處理，Ambient Mesh需要經過兩個ztunnel以及一個waypoint，肉眼可見地又額外增加了一跳，因此完整的L7處理需要額外經過三跳。雖然社群聲稱這對效能的影響很小，但是仍需待其特性穩定後進一步觀察對比；
2. 容器網路適配：雖然Ambient Mesh與應用基本實現了完全解耦，但是反過來也增加了網格與底層基礎設施的耦合，Sidecar模式僅需在Pod的net ns實現流量的攔截處理，但是Ambient Mesh在主機網路進行流量攔截，顯然需要更多考慮與底層容器網路的適配；
3. 配置複雜：原本Envoy複雜的配置就被廣為詬病而Ambient Mesh更需要實現一個ztunnel對節點所有Pods的代理，配置複雜度更是上升一個數量級，同時配置的複雜意味著處理流程的增加，也會對資料面的排錯以及整體效能造成影響；
4. 其他：ztunnel的高可用？waypoint事實上將原本雙端的L7處理變為了單端，對L7監控指標正確性的影響？…
未來展望
從版本釋出的角度，自從2022年9月份釋出以來，Ambient Mesh一直作為實驗特性存在於獨立的分支之中。因此對於Ambient Mesh下一步的計劃就是合入主幹分支（已於2023年2月實現）並作為Alpha特性發布，最終在2023年底到達Stable，實現生產可用。
從API的角度，最理想的是能在兩種架構下共用同一套API。當然這是不現實的，因為已有的一部分Istio API是以Sidecar模式部署為前提條件設計的。最典型的就是Sidecar這個CRD，它用於定製化下發至不同Sidecar的配置，從而減少Sidecar不必要的資源佔用。這些Sidecar-Only的API顯然在Ambient Mesh下毫無意義。同時，Ambient Mesh自身也引入了ztunnel和waypoint兩個獨有元件，因此Ambient Mesh也需要建立新的API，用於管理這些獨有元件以及實現一些Ambient Mesh Only的功能。最終Ambient Mesh會實現已有的核心Istio API（VirtualService, DestinationRules等）並建立一些其獨有的API，重要的是做到三類API（Sidecar模式獨有、Ambient Mesh獨有、兩者共有）統一的使用與互動。
那麼Ambient Mesh是否做到了對Sidecar模式使用場景的全覆蓋，從而讓Sidecar模式徹底退出歷史舞臺了呢？答案自然是否定的，類似於業界各種獨佔模式和共享模式之爭，Sidecar模式本質上是應用Pod對Proxy的獨佔。專屬的Proxy往往能保證更好的資源可用性，儘量避免其他應用的影響，確保高優先順序應用的正常執行。可以預見，最終兩種模式的混合部署，應用按需選擇代理模式是更為理想的方式。所以構建混合部署模式，保證該模式下兩種模式的良好相容性和統一的體驗也將是後續工作的重點。
總結
Sidecar模式對於Istio就像一場原型驗證，以一種最Kubernetes Native的方式快速展示網格技術的價值，搶佔使用者認知和市場。不過隨著Istio的落地逐漸進入深水區，開始在生產環境大規模部署，Sidecar模式就顯得力不從心了。此時Ambient Mesh以一種更符合大規模落地要求的形態出現，克服了大多數Sidecar模式的固有缺陷，讓使用者無需再感知網格相關元件，真正將網格下沉為基礎設施。
但是顯然Ambient Mesh並不是網格資料面架構演進的終點。當前還沒有一種網格資料面方案能在侵入性、效能、資源佔用等各個考量維度做到完美。Ambient Mesh基本做到了對應用的零侵入，但是L7的三跳處理引發的效能問題，ztunnel等常駐程式的資源佔用令人無法忽視；gRPC等RPC庫透過內建實現xDS，直連Istio控制面，將網格雜糅進SDK，確實能實現很好的效能和資源佔用表現，只是不可避免地需要付出與應用強耦合、多語言支援複雜度高等固有代價；基於eBPF直接將全套網格資料面功能像TCP/IP協議棧一樣下沉到核心貌似是理想的終局方案，只是考慮到核心安全以及與核心互動的複雜性，eBPF的執行環境其實是非常受限的，例如eBPF程式載入到核心前必須經過verifier的校驗，執行路徑必須完全已知，無法執行任意的迴圈。因此對於HTTP/2，gRPC等複雜的L7處理，基於eBPF的開發和維護都會比較困難。
考慮到基礎設施對效能、資源損耗的極致要求以及過往相關技術的演進規律，例如對於基礎網路，絕大多數應用共享使用核心協議棧即可，部分特殊應用利用DPDK，RDMA等專用技術進行加速。同樣，對於網格資料面，多種技術結合，分別最佳化相應場景的解決方案，可能是更具可行性的。可以預見，這類方案基本上是以類Ambient Mesh的節點級代理作為主體，隨著網格以及eBPF技術的發展，將盡量多的網格資料面功能下沉至eBPF（Fast Path）實現；少部分高階功能交由使用者態的Proxy（Slow Path）實現；那些對效能、隔離性等有較高要求的應用，則為其部署專屬的Sidecar。這樣一來，就能滿足絕大多數場景下，對侵入性、效能、資源佔用等各個維度的要求。
綜上 ，最終是一套資料面方案一統天下，還是各種方案混合部署，取各家所長，仍有待對相關技術不斷探索演進，再用實踐檢驗，最後讓時間告訴我們答案。
參考文獻
[1] Istio Ambient Mesh Explained: https://lp.solo.io/istio-ambient-mesh-explained
[2] What to expect for ambient mesh in 2023: https://www.solo.io/blog/ambient-mesh-2023
[3] Introducing Ambient Mesh: https://istio.io/latest/blog/2022/introducing-ambient-mesh
[4] Get Started with Istio Ambient Mesh: https://istio.io/latest/blog/2022/get-started-ambient