Istio Ambient Mesh七層服務治理圖文詳解
摘要：本文主要集中剖析Ambient mesh七層服務治理相關內容。
本文分享自華為雲社群《Istio Ambient Mesh七層服務治理圖文詳解》，作者：華為云云原生團隊。
由於Ambient mesh的工作原理比較複雜，我們在上一篇文章《深度剖析！Istio共用代理新模式Ambient Mesh》中主要剖析了Ambient mesh四層流量治理。因此本文主要集中剖析七層治理部分。建議在閱讀本文之前，讀者朋友先瀏覽上一篇文章。
Ambient Mesh七層治理架構
Ambient mesh預設對服務只進行四層治理，使用者需要通過定義Gateway資源物件顯式的啟動七層治理。
apiVersion: gateway.networking.k8s.io/v1alpha2 kind: Gateway metadata: name: productpage annotations: istio.io/service-account: bookinfo-productpage spec: gatewayClassName: istio-mesh
七層治理架構
如圖所示，相比Ambient mesh四層服務治理，七層服務治理增加了新的waypoint元件，這是七層治理的核心元件，本質上waypoint也是通過envoy實現。服務網格七層的治理策略均作用在waypoint上。Sidecar模式Istio七層治理時，流量在使用者端和伺服器端的Sidecar中分別進行七層協定的編解碼等操作；而七層流量在Ambient mesh中，七層流量的處理只在一個waypoint中。預設， Pilot通過監聽Gateway物件，負責建立單範例的waypoint，那麼所有的到Productpage的七層流量均由waypoint代理。生產環境中，單範例waypoint往往不滿足高可用、高並行的要求，因此waypoint的擴容策略還需要使用者通過第三方軟體例如HPA來實現。
Ambient Mesh七層流量治理詳解
本例服務部署模型
Sleep傳送側流量處理
（1）sleep存取productpage的流量被同節點的tunnel以TPROXY（透明代理）方式攔截轉發到ztunnel(監聽127.0.0.1:15001)，使用TPROXY的好處是保留原始的目的地址，ztunnel做轉發時必須依賴原始目的地址。這裡的攔截方式與前一篇文章中講的四層流量治理的攔截完全相同，因為在Ambient Mesh中網路層的攔截完全不感知應用層L7協定。
-A PREROUTING -i pistioout -p tcp -j TPROXY --on-port 15001 --on-ip 127.0.0.1 --tproxy-mark 0x400/0xfff
（2）ztunnel通過ztunnel_outbound監聽器，監聽在15001埠。ztunnel_outbound監聽器與Istio Sidecar模式的監聽器完全不同，它包含所有本節點上的服務到整個網格其他服務的FilterChain（過濾器鏈）。
ztunnel_outbound監聽器
ztunnel_outbound監聽器如何選擇合適的FilterChain處理流量的呢？如下圖所示，ztunnel_outbound監聽器中設定了filter_chain_matcher。其中通過匹配封包的源IP（10.244.1.4，即sleep容器的地址）、目的IP（10.96.179.71，即produtpage服務的ClusterIP）及目的埠（9080即productpage伺服器埠號），可以選擇名稱為"spiffe://cluster.local/ns/default/sa/sleep_to_server_waypoint_proxy_spiffe://cluster.local/ns/default/sa/bookinfo-productpage"的FilterChain來處理Sleep發往Productpage的請求。
FilterChain 匹配器
（3）"spiffe://cluster.local/ns/default/sa/sleep_to_server_waypoint_proxy_spiffe://cluster.local/ns/default/sa/bookinfo-productpage" FilterChain，包含一個TCPProxy過濾器，並且關聯到與FilterChain同名的Cluster。即存取請求交由同名的 Cluster處理
FilterChain
（4）"spiffe://cluster.local/ns/default/sa/sleep_to_server_waypoint_proxy_spiffe://cluster.local/ns/default/sa/bookinfo-productpage" Cluster為EDS型別，包含的Endpoint地址為10.244.1.8:15006，即waypoint容器的監聽地址。後面我們可以看到waypoint中有監聽器監聽在15006埠。此Cluster負責將流量進行加密，然後傳送到waypoint（10.244.1.8:15006）。
Sleep到Productpage的Cluster
Sleep到Productpage的Endpoint
Waypoint轉發
（1）Waypoint首先通過」inbound_CONNECT_terminate」監聽器接收Sleep存取Productpage的請求。此監聽器上面設定有DownstreamTlsContext，其負責對下游請求進行TLS終止。另外此監聽器只有一個FilterChain，包含用於處理HTTP請求的HTTP Connection Manager過濾器。它的核心思想是通過匹配Authority（10.96.179.71:9080，也是原始目的地址）以及CONNECT請求方法進行路由，匹配成功後，選擇」inbound-vip|9080|internal|productpage.default.svc.cluster.local」 的 Cluster進行處理。
inbound_CONNECT_terminate監聽器
（2）」inbound-vip|9080|internal|productpage.default.svc.cluster.local」 Cluster是一個內部靜態型別Cluster，其主要是將流量遞交給內部VIP監聽器」inbound-vip|9080||productpage.default.svc.cluster.local」，不做其他額外的處理。
Internal productpage cluster
（3）Vip監聽器非常重要，一些服務治理策略，比如VirtualService設定的路由策略都在此監聽器中載入，這裡我們沒有設定任何的策略，因此它主要是通過"inbound-vip|9080|http|productpage.default.svc.cluster.local" Cluster進行負載均衡，將將流量轉發到Pod監聽器處理。
Inbound-vip監聽器
Inbound vip cluster
Inbound endpoint
（4）Pod 監聽器上會設定服務相關的策略，包括認證、鑑權、Telemetry等策略。這裡我們並沒有設定任何的流量治理策略，因此Pod監聽器比較簡單，沒有複雜的過濾器。
在本例中，我們啟動了兩個Productpage服務範例，假設經過"inbound-vip|9080|http|productpage.default.svc.cluster.local" Cluster負載均衡後，流量被轉發到10.244.2.8這個Pod監聽器。那麼流量進而被關聯的"inbound-pod|9080||10.244.2.8" Cluster接管。
Inbound-pod監聽器
（5）"inbound-pod|9080||10.244.2.8" 是一個靜態的Cluster，其主要設定建立CONNECT 相關的metadata，然後將流量轉發給」 inbound_CONNECT_originate」監聽器
Inbound pod cluster
（6）」inbound_CONNECT_originate」監聽器是waypoint處理流程中的最後一個過濾器，它會通過HTTP Connect方法告訴目標ztunnel建立到"%DYNAMIC_METADATA(tunnel:destination)%的隧道，這裡CONNECT地址即10.244.2.8:9080。並且通過「set_dst_address」將封包的目的地址設定為10.244.2.8:15008。
Inbound connect originate監聽器
（7）」 inbound_CONNECT_originate」 Cluster為ORIGINAL_DST型別，並且設定有TLS Context。因此最後經過TLS加密後，封包最終被髮往10.244.2.8:15008。
Inbound connect originate Cluster
Productpage接收流量處理
Productpage接收測七層的流量處理與四層處理完全相同，請參考https://bbs.huaweicloud.com/blogs/375712
Ambient Mesh七層流量治理小結
七層服務存取資料流
sleep存取productpage的範例中，我們為productpage建立了Gateway，因此Ambient mesh將啟動waypoint，代理所有存取productpage的七層流量流量。前面我們深入分析了ztunnel和waypoint中每一個監聽器、每一個Cluster的工作原理，看起來可能會很複雜。故在此通過上圖進行一個結構性的總結，我們發現在通訊的過程中，七層的治理流程明顯比四層複雜：
1. 傳送側的路由、iptables：將流量攔截到ztunnel的15001埠
2. 傳送側ztunnel：將productpage請求轉發到waypoint
3. Waypoint七層處理：將請求通過四個監聽器依次處理，最後傳送到接收端
4. 接收側的路由、iptables：將流量攔截到ztunnel的15008埠
5. 接收ztunnel：virtual_inbound監聽器及關聯的cluster
Ambient Mesh七層流量治理總結和展望
Istio Sidecar模式下，七層HTTP處理分別在使用者端的Sidecar和伺服器端的Sidecar中進行。而Ambient mesh中，七層HTTP處理僅在waypoint中進行。理論上，七層流量的處理比較複雜，同時比較耗時，所以ambient mesh在這一層面具有一定的優勢。但是實際場景中，waypoint的部署位置是不確定的，它可能與使用者端、伺服器端在同一節點上，也有可能與他們任何一方分佈在不同的節點，甚至在不同的可用區。所以單純從時延的角度，很難判斷Istio 經典Sidecar模式和Ambient mesh孰優孰劣。
當前Ambient mesh負責waypoint的生命週期，但是隻支援了單範例部署，並且沒有提供動態擴縮容能力，而實際生產中服務請求往往有明顯的峰谷特徵，所以Ambient mesh沒有應對突發大流量的能力。
Ambient mesh中，每一個服務身份使用獨立的waypoint代理自身的存取，這一點在安全性上與Sidecar模式類似，不用擔心共用帶來的安全性降低。
整體來看，Ambient mesh七層治理架構並沒有太大的優勢，主要是補充Ambient mesh四層共用代理ztunnel。未來首要解決的就是waypoint本身自動化的問題，必須能夠根據服務當前的負載動態擴縮容。
從實現角度來看，waypoint的監聽器處理鏈過長，容易產生重複的計算和處理，並且在開發者角度，過多的xds設定不易維護。因此簡化waypoint處理也是長期效能優化的一個主要方向。
Istio Sidecar模式基於Revision的優雅升級目前已經GA，但是Ambient mesh本身由於共用代理的原因，優雅升級功能基本被破壞殆盡。作為微服務的基礎設施，Ambient mesh如何支援Revision的優雅升級也將是未來社群關注的頭等大事。