服務網格中 sidecar 流量治理與多協議嗅探

語言: CN / TW / HK

:point_up_2: 點擊“ 博文視點Broadview ”,獲取更多書訊

服務網格架構已經是一個老生常談的問題,服務的進出口流量經過 iptables 等技術手段被劫持到 sidecar,經由 sidecar 觀察、治理之後再被轉發到實際目標服務或者實例。

那麼,在 sidecar 內部流量是如何處理並正確應用治理規則和轉發的呢?

更具體一點,某個服務訪問其他服務時,流量被劫持到到 sidecar 之後:

  • 如何確認流量原始目標地址並實現正確轉發?

  • 如何確認哪些治理規則需要對當前流量生效?

接下來,本文將以 envoy sidecar 實現為例一點點説明 sidecar 是如何解決以上兩個問題的 (服務入口流量劫持和處理相對簡單,所以本文主要關注出口流量處理)。

0 1

只是代理

説一千,道一萬,envoy sidecar 也只是最簡單不過的代理而已,它所有能做的事情都不會超過代理的範疇。

回顧代理的通用工作機制 :接受下游連接和請求,按需對請求解析,然後經過一系列的模塊或過濾器處理之後,將請求轉發給上游服務。

在 envoy sidecar 中,接受下游的連接和請求的模塊被抽象為 listener,而上游服務則被抽象為 cluster,形成如下結構:

當然,envoy 支持多 listener 機制,即同時監聽複數個地址,並且可以通過 xDS 協議實現 listener 的動態更新。並且,envoy 允許 listener 並不實際綁定地址和端口,即不產生實際的地址監聽。這兩個特性對於 sidecar 來説很關鍵,不過並不複雜。

在對 sidecar 本身最簡單的結構有了基本的瞭解之後,接下里就可以正式開始回答之前的問題了。

0 2

你去哪兒?

第一個問題,流量劫持之後,如何確認原始的目標地址並轉發?

一般來説,sidecar 會創建兩個特殊的 listener 並打開端口監聽。一個作為服務入口流量劫持的入口(virtual inbound),一個作為服務出口流量劫持的入口(virtual outbound)。服務進出口流量被劫持後被分別發送 sidecar 這兩個特殊 listener 處理。

以出口流量的 virtual outbound 為例。 數據流量經過 iptables 劫持和重定向之後和 virtual outbound 建立連接。而 virtual outbound 則可以使用 系統調用通過 SO_ORIGINAL_DST 獲得該連接原始目標地址(IP 地址和端口)。該原始目標地址就可以用於輔助後續流量的轉發。

當然,對於部分的應用層協議來説,其協議消息本身就可能會攜帶目標服務的相關信息。sidecar 也可以在對流量內容解析之後,根據其中的信息識別目標服務並轉發。

舉個例子,HTTP 協議。 當客户端使用域名訪問目標服務時,該域名就會直接被添加到請求的 host 當中。

根據配置,sidecar 也可以使用請求消息中的 host 將 HTTP 請求轉發給目標服務。根據應用層消息中服務標識選擇目標服務轉發也是一個關鍵特性,在後續內容中還會提到。

0 3

路在何方?

在服務網格中,sidecar 的職責當然不只是簡單的流量轉發了,更重要的是流量觀察及流量治理。所以,獲取到了流量原始目標 IP 和端口之後,直接轉發出去顯然不是網格想要的,必須進行更進一步的治理。

這就是第二個問題了,如何使治理規則生效,又有哪些治理規則需要對當前流量生效呢?

答案其實就在第1小節中。作為代理的 sidecar 本身就具備流量觀察、流量治理、負載均衡等基礎能力,流量自 listener 進入,經過過濾器處理,最終通過 cluster 轉發給目標服務。

同時,envoy sidecar 又具備靈活的多 listener 機制,且允許 listener 不產生實際監聽。

那麼,sidecar 完全可以為每一個服務創建一個不會實際監聽地址的內部 listener (簡稱為 fake listener),以服務 VIP(注意,是服務 VIP,一個服務可能有很多個實例,每個實例都有實例 IP,但是一個服務一般只有一個 VIP)為索引。 而所有與該服務相關的治理規則,都以各種過濾器配置下發到該 fake listener 當中。不同 fake listener 可以使用不同過濾器配置。

如上圖所示,上層服務抽象中的服務以及治理規則最終被映射為 sidecar 中具體的 listener 和過濾器。

一般來説,在 K8S 的服務模型當中,客户端服務會使用目標服務域名訪問目標服務。目標服務域名經 DNS 解析為目標服務 VIP。訪問流量經 iptables 劫持,自 virtual outbound 進入 sidecar,在使用 SO_ORIGINAL_DST  獲得流量原始目標地址(也即目標服務 VIP 地址和端口)之後,搜索該原始目標地址對應的 fake listener,然後把連接整個交給該 fake listener 處理,該 fake listener 會負責應用對應服務的治理規則(以過濾器實現)並將流量最終轉發給目標服務(以 cluster 實現)。

0 4

公共的路

前文説過,sidecar 為每個服務都創建一個對應的 listener,以服務 VIP 為索引。可是如果存在大量的服務,那麼就會創建大量的 listener,帶來更大的資源開銷。

另外,並不是所有服務模型中都有 VIP。比如在 Dubbo 的微服務模型中,就沒有 VIP 的位置,所以就必須為每個實例創建一個 listener 保證流量被正確的治理和轉發。且相同服務的所有實例對應的多個 listener 會應用相同的治理規則。

如此,顯然會帶來配置和資源的膨脹,給控制面和數據面都帶來壓力。

為了緩解該問題,envoy sidecar 提供了通配的 fake listener。通配 fake listener 使用 0.0.0.0:<port> (IPv4)為索引。

當以流量原始目標地址無法搜索到對應 fake listener 之後,就會根據流量原始目標端口搜索對應的通配 fake listener 來處理該流量。舉例來説,如果一個請求(連接 or 流量)原始目標地址為 1.2.3.4:80,但是 sidecar 中不存在 1.2.3.4:80 fake listener 時,該請求就會被交由 0.0.0.0:80 通配 fake listener 處理。多個不同的 Dubbo 服務實例,也可以只創建一個對應的 fake listener。

但是,顯然,通配 fake listener 會引入一些新問題。

首先, 多個不同服務的流量最終會被同一個 fake listener 處理,為了保證服務治理規則能夠正確、準確的生效,該通配 listener 內部必須要根據請求消息內服務標識(如 HTTP 中 host 請求頭,如 Dubbo 請求中 interface)識別流量的目標服務並應用治理規則。

其次, 通配 fake listener 可能會帶來協議衝突問題。一般來説,同一地址(相同 IP,相同端口)只會使用一種協議(一般如此,當然也存在特殊情況,暫不討論)。

可是,現在多個不同目標目標流量都可能聚集到同一 fake listener,必然存需要在同一 fake listener 處理多種不同協議流量的場景。 比如説, 目標地址 1.2.3.4:8080 提供 Dubbo 服務,目標地址 2.3.4.5:8080 提供 HTTP 服務,指向兩者的流量最終都被 0.0.0.0:8080 處理。為了解決該問題,envoy sidecar 提供了協議嗅探機制,在同一 listener 中處理不同協議流量。

0 5

選擇車道

如前文所述,請求流量和連接最終會交由 listener 處理,並以各種過濾器來實現各種治理規則,並且由於通配 fake listener,會大量出現需要在同一 listener 中處理不同協議流量的能力。

不同協議,可能有完全不同的消息格式和模型,顯然需要不同的過濾器來進行處理。在 envoy sidecar 中就有相關的機制來支持該場景。

在 sidecar 的 listener 中,可以同時配置多組不同的過濾器,每組過濾器稱為一個 filter chain。並且還提供了名為 listener filter 的特殊過濾器,可以對流量和連接進行預處理,並根據預處理的結果選擇不同的 filter chain。

再次以 Dubbo 和 HTTP 協議為例。

當一個新的連接在 fake listener 中建立時,會首先經過 listener filter 預處理。 它們會預讀該連接上少量字節,如果其中包含 Dubbo Magic Number 和消息類型等字節,則為 Dubbo 協議;如果包含 HTTP 協議行,則為 HTTP 協議。最終 sidecar 會根據協議的不同選擇不同的 filter chain 來處理,實現協議嗅探的效果。

利用好協議嗅探,就可以充分利用通配 listener 的能力,避免出現協議衝突。同時,對於同一地址(相同服務 IP,相同端口)不同協議的情況,也可以很好的處理。

本文以儘可能淺顯的概念來説明服務網格中流量治理的實現原理與多協議嗅探機制要解決的問題。希望能夠讓讀者對於服務網格流量治理和協議嗅探能有一個基本認知。更多相關內容可以閲讀 《深入理解Isito:雲原生服務網格進階實戰》 一書。

京東滿100減50,掃碼即購!

內容簡介

Istio 在 1.5 版本後有了重大的架構變化,同時引入或改進了多項功能,例如,引入了智能 DNS 代理、新的資源對象,改進了對虛擬機的支持等。

本書以 Istio 新版本為基礎編寫而成,在持續追蹤 Istio 社區最新動向的基礎上,力求為讀者提供最新、最全面的內容。

本書共10章,分別從概念、實踐和生態擴展3個層面為讀者系統介紹了Istio的知識。

本書特色

特色1: 雲原生社區是我國服務網格技術推廣的先驅陣地。本書由雲原生社區多位技術專家合力撰寫完成,內容專業,質量保障。

特色2: 本書經多次修訂,基於Isito較新的版本和特性進行講解。

特色3: 本書圖文並茂,示例豐富,包含進階,既能夯實基礎,又能突破瓶頸。

大咖讚譽

Service Mesh已深入人心,近些年演化出的Database Mesh、Event Mesh、IO Mesh、Chaos Mesh等都在快速發展,這些充滿活力的理念和項目一定會掀起一股新的Mesh浪潮。

——張亮   SphereEx創始人、Apache ShardingSphere VP

雲原生社區組織了一批貢獻者對Istio做了深入解讀和實踐分享,能讓技術團隊少走彎路、少踩坑,真正領悟服務網格的價值。

——劉超   騰訊雲T4架構師

假以時日,相信Istio必將大放異彩。當此時刻,這本《深入理解Istio:雲原生服務網格進階實戰》足以滿足我們對服務網格的所有期待。

——費良宏   Amazon Web Service首席架構師

本書彙集了雲原生社區多名工程師的實踐經驗,由淺入深,全面介紹了Istio的功能、原理及高階實戰經驗,是一本難得的從入門到進階技術書。

——徐中虎   Istio社區Steering Committee,華為雲原生開源團隊核心成員

本書詳細介紹了Istio新架構中的各個組件、功能及相關生態。相信大家可以從中學習到成熟的Service Mesh技術和架構設計思想。

——吳晟   Tetrate創始工程師、Apache SkyWalking創始人、Apache軟件基金會首位中國董事

知識匯聚成書,經驗落於文字,Istio龐大的體系架構和紛繁複雜的特性得以被清晰地呈現。相信這本書可以幫助讀者瞭解Istio,掌握Istio。

——敖小劍   ervice Mesh佈道師

面向讀者