Ambient Mesh：Istio 資料面新模式

摘要：基于Istio對于Kubernetes生態的完美補充，隨著Kubernetes的大規模普及，Istio 資料面新模式 —Ambient MeshIstio也實作了對用戶心智以及市場的快速搶占，

本文分享自華為云社區《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 資料面新模式 —Ambient MeshIstio也實作了對用戶心智以及市場的快速搶占，

雖然以Sidecar模式部署Istio資料面似乎是一個理所應當，讓人無法拒絕的選擇，但是需要強調的是，Istio完整功能的實作并不與Sidecar模式強系結，我們還有各種各樣其他的選擇，另1外，隨著對于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的控制面與原先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模式缺陷的對立面：

2. 對于為什么要對L4/L7進行分層處理，首先要區分兩者之間的區別，與L4相比，L7的處理更為復雜，需要占用更多的CPU/記憶體等資源，不同型別的操作之間資源占用也存在較大差別；同時操作越復雜暴露的攻擊面越大，另外Envoy當前并不支持對不同租戶的流量進行強隔離，“Noisy Neighbor”的問題不可避免，因此Ambient Mesh分層處理架構的優勢如下：

當然Ambient Mesh作為Istio全新的資料面架構，在社區中依然以實驗特性的形式存在，仍然有許多問題亟待解決，例如：

未來展望

從版本發布的角度，自從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程式加載到內核前必須經過verififier的校驗，執行路徑必須完全已知，無法執行任意的回圈，因此對于HTTP/2，gRPC等復雜的L7處理，基于eBPF的開發和維護都會比較困難，

考慮到基礎設施對性能、資源損耗的極致要求以及過往相關技術的演進規律，例如對于基礎網路，絕大多數應用共享使用內核協議堆疊即可，部分特殊應用利用DPDK，RDMA等專用技術進行加速，同樣，對于網格資料面，多種技術結合，分別優化相應場景的解決方案，可能是更具可行性的，可以預見，這類方案基本上是以類Ambient Mesh的節點級代理作為主體，隨著網格以及eBPF技術的發展，將盡量多的網格資料面功能下沉至eBPF（Fast Path）實作；少部分高級功能交由用戶態的Proxy（Slow Path）實作；那些對性能、隔離性等有較高要求的應用，則為其部署專屬的Sidecar，這樣一來，就能滿足絕大多數場景下，對侵入性、性能、資源占用等各個維度的要求，

綜上 ，最終是一套資料面方案一統天下，還是各種方案混合部署，取各家所長，仍有待對相關技術不斷探索演進，再用實踐檢驗，最后讓時間告訴我們答案，

參考文獻

點擊關注，第一時間了解華為云新鮮技術~

標籤：其他

上一篇：常用心理測驗精選題庫ACCESS資料庫

下一篇：返回列表