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接收測七層的流量處理與四層處理完全相同，請參考//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的優雅升級也將是未來社區關注的頭等大事。

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

Tags: Ambient Mesh istio 華為雲新鮮技術分享