生產環境的 ServiceMesh 流量劫持怎麼搞？百度有新招

 

 背景

 

ServiceMesh 社區使用 iptables 實現流量劫持，這個機制在百度生產環境使用會遇到一些問題，所以，咱們探索了其餘的流量劫持方式，如基於服務發現的流量劫持機制、基於 SDK 的流量劫持機制、基於固定 Virutal IP 的流量劫持機制等。

 

本文主要介紹基於服務發現的流量劫持機制，這個機制是在服務發現步驟 "僞造" 地址來完成流量劫持。

 

 基於 iptables 流量劫持機制

 

咱們先簡單的看看社區的流量劫持方案，首先看下 Inbound 流量劫持，如圖1 所示：

 

1. 全部入站流量都會通過 iptables；

2. iptables 忽略非 TCP 以及訪問 istio 管理端口的流量，將其餘入站流量轉發給 Envoy；

3. Envoy 處理完後再將流量轉發給 App；

4. 上述流量又一次通過 iptables 規則匹配，iptables 將具有如下特色的流量當作 Envoy 發出的流量直接轉發給目的地：

   1. Envoy 發出的；

   2. 輸出設備時 lo；

   3. 目的地時127.0.0.1。

 

至此 iptables 完成了 Envoy 對 Inbound 流量的劫持和轉發。

 

圖1 iptables 流量劫持

 

接下來我們再來看看 Outbound 流量劫持，如圖2所示：

 

1. App 給 Server 發送流量；

2. iptables 將知足如下條件的流量轉發給 Envoy：

   1. 不是 Envoy 發出的；

   2. 輸出設備不是 lo；

   3. 目的地址不是 localhost。

3. Envoy 處理完後，選定 Server 的一個 endpoint 轉發流量；

4. iptables 將知足如下條件的流量直接發給目的地，也就是 Server：

   1. Envoy 發出的；

   2. 輸出設備不是 lo。

圖2 iptables 劫持 outbound 流量

 

至此，iptables 完成了 inbound 和 outbound 的流量劫持，該機制的好處在於能夠透明的劫持業務流量，可是在百度生產環境使用時存在一些問題：

 

• 可管控性差，內網各容器網絡沒有隔離，iptables 是全局工具，可被其它用戶修改，致使流量劫持異常；它做爲單機流量管理工具，沒有成熟的平臺/產品進行統一的管理。

• 大併發場景下存在必定的轉發性能問題；規則數過多時變動時延大。

 

所以咱們探索了其餘的劫持機制，接下來我來介紹下百度生產環境正在使用的流量劫持機制——基於服務發現的流量劫持機制。

 

 基於服務發現的流量劫持機制

 

先來看下該機制的設計思路，服務流量根據方向的不一樣，能夠分爲 Outbound 和 Inbound。如圖3 所示，有兩個服務：Client 和 Server，Client 的 Envoy 記爲 EnvoyC，Server的 Envoy 記爲 EnvoyS（本質是同樣的，只不過爲了表述方便取了不一樣的名字）。EnvoyC 要劫持的流量是來自在相同機器上的 Client 發出的 Outbound 流量，而 EnvoyS 要劫持的流量大部分是來自不一樣機器上的服務發給 Server 的流量。

 

這兩種流量的劫持機制能夠分開設計，考慮到 ServiceMesh 經常使用的策略都在 EnvoyC 上生效，所以咱們先設計了 EnvoyC 劫持 Outbound 流量的方案。

 

圖3 ServiceMesh 流量劫持

 

Outbound 流量劫持

 

一個完整的請求大概要經歷域名解析（或者是服務發現）、創建鏈接、發送請求這幾個步驟，如今 iptables 用不了，其餘依賴 Kernel 的劫持方案暫時也用不了，咱們將目光轉向第一步——服務發現。百度生產環境的服務基本都依賴 Naming 系統來解析服務真實的 ip 列表，咱們只須要讓 Naming 系統返回 Envoy 的 ip 地址，就能將服務的 Outbound 流量劫持到 Envoy。

 

如圖4 所示，Naming Agent 是單機上負責服務發現的 Agent。Client 在發送請求前，會先去 Naming Agent 問：我想給 Server 發個請求，請給我他的地址。這時候 Naming Agent 就會把 Envoy 的地址當成 Server 的地址告訴 Client。接下來 Client 就會乖乖的把請求發給 Envoy，Envoy 再根據一系列的策略把請求轉發給 Server。

 

圖4 Outbound 流量劫持

 

這種劫持機制的好處在於改造事項集中在 Naming 系統，使用該 Naming 系統的服務都能經過該方案透明的完成 Outbound 流量劫持。

 

另外，基於 Naming 系統的流量劫持機制能夠動態回傳流量治理參數給業務服務，如超時、重試等。這種能力的其中一個用途是能夠避免 Mesh 劫持後的多級重試致使服務雪崩，具體作法如圖5 所示，當業務流量被 Envoy 劫持後，Envoy 會經過 Naming Agent 將業務服務的重試次數置爲0。

 

圖5 動態回傳流量治理配置

 

 

此外，爲了下降數據面（Envoy）故障時對業務服務的影響，咱們還增長了數據面自動容災、主動關閉 Mesh 等能力：

 

• 數據面故障自動容災能力：當 Envoy 異常時，Naming Agent 會自動返回 Server 實際的實例列表，此時，Client 會自動回退爲非 Mesh 劫持模式。

• 主動關閉 Mesh 劫持：用戶也能夠主動關閉 Mesh 劫持，此時，Client 也會自動回退爲非 Mesh 劫持模式。

 

至此，Envoy 可以劫持 Outbound 流量，可是，只有 Outbound 流量劫持能力的 Envoy 是不完整的，對於入口限流等功能，還須要具有 Inbound 流量劫持的能力。

 

Inbound 流量劫持

 

Inbound 流量主要來自其餘機器，咱們沒法再依賴單機的 Naming Agent 僞造地址，得另尋出路。仍是基於 Naming 系統的思路，EnvoyS 和 Server 是同機部署的，他們對外提供的地址，惟一的區別在於端口，所以，只要咱們能更換 EnvoyC 訪問 Server 時的端口，就能將 Inbound 流量劫持到 EnvoyS。

 

如圖4 所示，EgressPort 接收 Outbound 流量，IngressPort 接收 Inbound 流量。

 

1. 控制面（Istio）將 EnvoyS 的 IngressPort 做爲 Server 的端口下發給 EnvoyC；

2. EnvoyC 將訪問 Server 的流量轉發到 IngressPort，被 EnvoyS 收到。

3. EnvoyS 再將流量轉發到 Server 服務端口 NamedPort。

 

 

 

至此，Envoy 具有了部分 Inbound 流量劫持能力，爲何說是部分呢，由於這種機制沒法劫持入口服務的流量。入口服務的上游（Client）是外部服務，它的配置不受 Istio 控制，也就沒法採用該機制完成流量劫持，後續需進一步完善該能力。

 

Inbound 流量劫持中的坑

 

除了上面提到的問題，Inbound 流量劫持還存在一些坑。咱們發現當 EnvoyS 劫持了 Inbound 流量後，L3/L4 層通訊協議的部分健康檢查機制失效。

 

L3/L4 層通訊協議的主動健康檢查部分功能失效

 

緣由：L3/L4 層通訊協議的主動健康檢查默認是檢查端口存活，當流量被劫持到 EnvoyS 後，該功能實際檢查的是 EnvoyS 的 IngressPort 端口存活，也就沒法反饋 Server NamedPort 端口存活狀況。

 

咱們目前採用的解決方案是採用兩段式主動健康檢查機制，兩段分別是：

 

1. Envoy 間健康檢查：EnvoyC 對 EnvoyS 的健康檢查，該健康檢查可以反饋 EnvoyS 和 Server 的狀態。

2. Envoy 和本地 Service 間健康檢查：EnvoyS 檢查 Server 端口存活狀況，檢查結果由 EnvoyS 反饋給 EnvoyC。
    

L3/L4 層通訊 協議的異常點驅逐（被動健康檢查）功能失效

 

緣由：L3/L4 層通訊協議的異常點驅逐條件是鏈接異常，當流量被劫持到 EnvoyS 後，該功能實際上檢查的是 EnvoyC 可否正常的跟 EnvoyS 創建鏈接，而不是 Server。

 

咱們目前採用的解決方案是完善L3/L4 層通訊協議的驅逐條件，增長訪問超時做爲驅逐條件。所以，當 Server 異常時，EnvoyC 會由於一直沒法獲得應答，而將該下游標記爲異常。

 

 總結

 

最後簡單的對比下上述兩種方案：

 

 

基於服務發現的流量劫持機制目前已應用在百度App、信息流、百度地圖等業務線的數百個服務、數萬個實例上。這種流量劫持機制可以減小轉發性能的損耗，具有數據面故障自動容災能力，可以動態回傳流量治理參數。可是該機制也缺失一些能力：沒法劫持入口服務的流量，後續咱們將進一步補齊該能力。

 

最後，百度雲原生團隊在2021年將持續爲你們帶來 Service Mesh 系列文章，內容涵蓋 Istio 入門體驗、Istio 和 Envoy 源碼深度解析、服務網格大規模落地經驗、服務網格性能優化等，敬請持續關注。

 

---

 

關於百度智能云云原平生臺

 

百度智能云云原平生臺，爲客戶建設容器化和無服務器化的基礎設施，提供企業級的微服務治理能力，同時集成源自百度自身多年實踐的 DevOps 工具鏈。可以保障開發者享受到高效、靈活、彈性的開發與運維體驗，助力企業更高效率低風險地構建雲原生應用，普遍應用於金融、互聯網、製造等各行各業的雲原生轉型階段。

 

其中天合 Stack 是私有化雲原生技術中臺，包含基於 Kubernetes 的容器雲平臺、基於 Istio 和 SpringCloud 架構的微服務平臺和自研函數計算服務三部分，每部分都可獨立提供服務。

 

點擊https://cloud.baidu.com/product/cnap.html，查看百度雲原平生臺詳情。

 

相關閱讀：

雲原生時代，你應該瞭解的Service Mesh

2021年 Istio 大型「入坑」指南

 

 

---

 

重磅！雲原生計算交流羣成立

掃碼添加小助手便可申請加入，必定要備註：名字-公司/學校-地區，根據格式備註，才能經過且邀請進羣。

瞭解更多微服務、雲原生技術的相關信息，請關注咱們的微信公衆號【雲原生計算】！