摘要：本文主要集中剖析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的優雅升級也將是未來社區關注的頭等大事，
點擊關注，第一時間了解華為云新鮮技術~
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/527859.html
標籤：其他