生產(chǎn)環(huán)境的 ServiceMesh 流量劫持怎么搞

本篇內(nèi)容介紹了“生產(chǎn)環(huán)境的 ServiceMesh 流量劫持怎么搞”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

 背景

ServiceMesh 社區(qū)使用 iptables 實(shí)現(xiàn)流量劫持，這個(gè)機(jī)制在百度生產(chǎn)環(huán)境使用會(huì)遇到一些問題，因此，我們探索了其他的流量劫持方式，如基于服務(wù)發(fā)現(xiàn)的流量劫持機(jī)制、基于 SDK 的流量劫持機(jī)制、基于固定 Virutal IP 的流量劫持機(jī)制等。

本文主要介紹基于服務(wù)發(fā)現(xiàn)的流量劫持機(jī)制，這個(gè)機(jī)制是在服務(wù)發(fā)現(xiàn)步驟 "偽造" 地址來完成流量劫持。

 基于 iptables 流量劫持機(jī)制

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

1. 所有入站流量都會(huì)經(jīng)過 iptables；

2. iptables 忽略非 TCP 以及訪問 istio 管理端口的流量，將其他入站流量轉(zhuǎn)發(fā)給 Envoy；

3. Envoy 處理完后再將流量轉(zhuǎn)發(fā)給 App；

4. 上述流量又一次經(jīng)過 iptables 規(guī)則匹配，iptables 將具備以下特點(diǎn)的流量當(dāng)做 Envoy 發(fā)出的流量直接轉(zhuǎn)發(fā)給目的地：

1. Envoy 發(fā)出的；

2. 輸出設(shè)備時(shí) lo；

3. 目的地時(shí)127.0.0.1。

至此 iptables 完成了 Envoy 對(duì) Inbound 流量的劫持和轉(zhuǎn)發(fā)。

圖1 iptables 流量劫持

接下來咱們?cè)賮砜纯?Outbound 流量劫持，如圖2所示：

1. App 給 Server 發(fā)送流量；

2. iptables 將滿足以下條件的流量轉(zhuǎn)發(fā)給 Envoy：

1. 不是 Envoy 發(fā)出的；

2. 輸出設(shè)備不是 lo；

3. 目的地址不是 localhost。

3. Envoy 處理完后，選定 Server 的一個(gè) endpoint 轉(zhuǎn)發(fā)流量；

4. iptables 將滿足以下條件的流量直接發(fā)給目的地，也就是 Server：

1. Envoy 發(fā)出的；

2. 輸出設(shè)備不是 lo。

圖2 iptables 劫持 outbound 流量

至此，iptables 完成了 inbound 和 outbound 的流量劫持，該機(jī)制的好處在于可以透明的劫持業(yè)務(wù)流量，但是在百度生產(chǎn)環(huán)境使用時(shí)存在一些問題：

• 可管控性差，內(nèi)網(wǎng)各容器網(wǎng)絡(luò)沒有隔離，iptables 是全局工具，可被其它用戶修改，導(dǎo)致流量劫持異常；它作為單機(jī)流量管理工具，沒有成熟的平臺(tái)/產(chǎn)品進(jìn)行統(tǒng)一的管理。

• 大并發(fā)場景下存在一定的轉(zhuǎn)發(fā)性能問題；規(guī)則數(shù)過多時(shí)變更時(shí)延大。

因此我們探索了其他的劫持機(jī)制，接下來我來介紹下百度生產(chǎn)環(huán)境正在使用的流量劫持機(jī)制——基于服務(wù)發(fā)現(xiàn)的流量劫持機(jī)制。

 基于服務(wù)發(fā)現(xiàn)的流量劫持機(jī)制

先來看下該機(jī)制的設(shè)計(jì)思路，服務(wù)流量根據(jù)方向的不同，可以分為 Outbound 和 Inbound。如圖3 所示，有兩個(gè)服務(wù)：Client 和 Server，Client 的 Envoy 記為 EnvoyC，Server的 Envoy 記為 EnvoyS（本質(zhì)是一樣的，只不過為了表述方便取了不同的名字）。EnvoyC 要劫持的流量是來自在相同機(jī)器上的 Client 發(fā)出的 Outbound 流量，而 EnvoyS 要劫持的流量大部分是來自不同機(jī)器上的服務(wù)發(fā)給 Server 的流量。

這兩種流量的劫持機(jī)制可以分開設(shè)計(jì)，考慮到 ServiceMesh 常用的策略都在 EnvoyC 上生效，因此我們先設(shè)計(jì)了 EnvoyC 劫持 Outbound 流量的方案。

圖3 ServiceMesh 流量劫持

Outbound 流量劫持

一個(gè)完整的請(qǐng)求大概要經(jīng)歷域名解析（或者是服務(wù)發(fā)現(xiàn)）、建立連接、發(fā)送請(qǐng)求這幾個(gè)步驟，現(xiàn)在 iptables 用不了，其他依賴 Kernel 的劫持方案暫時(shí)也用不了，我們將目光轉(zhuǎn)向第一步——服務(wù)發(fā)現(xiàn)。百度生產(chǎn)環(huán)境的服務(wù)基本都依賴 Naming 系統(tǒng)來解析服務(wù)真實(shí)的 ip 列表，我們只需要讓 Naming 系統(tǒng)返回 Envoy 的 ip 地址，就能將服務(wù)的 Outbound 流量劫持到 Envoy。

如圖4 所示，Naming Agent 是單機(jī)上負(fù)責(zé)服務(wù)發(fā)現(xiàn)的 Agent。Client 在發(fā)送請(qǐng)求前，會(huì)先去 Naming Agent 問：我想給 Server 發(fā)個(gè)請(qǐng)求，請(qǐng)給我他的地址。這時(shí)候 Naming Agent 就會(huì)把 Envoy 的地址當(dāng)成 Server 的地址告訴 Client。接下來 Client 就會(huì)乖乖的把請(qǐng)求發(fā)給 Envoy，Envoy 再根據(jù)一系列的策略把請(qǐng)求轉(zhuǎn)發(fā)給 Server。

圖4 Outbound 流量劫持

這種劫持機(jī)制的好處在于改造事項(xiàng)集中在 Naming 系統(tǒng)，使用該 Naming 系統(tǒng)的服務(wù)都能通過該方案透明的完成 Outbound 流量劫持。

另外，基于 Naming 系統(tǒng)的流量劫持機(jī)制可以動(dòng)態(tài)回傳流量治理參數(shù)給業(yè)務(wù)服務(wù)，如超時(shí)、重試等。這種能力的其中一個(gè)用途是可以避免 Mesh 劫持后的多級(jí)重試導(dǎo)致服務(wù)雪崩，具體做法如圖5 所示，當(dāng)業(yè)務(wù)流量被 Envoy 劫持后，Envoy 會(huì)通過 Naming Agent 將業(yè)務(wù)服務(wù)的重試次數(shù)置為0。

圖5 動(dòng)態(tài)回傳流量治理配置

此外，為了降低數(shù)據(jù)面（Envoy）故障時(shí)對(duì)業(yè)務(wù)服務(wù)的影響，我們還增加了數(shù)據(jù)面自動(dòng)容災(zāi)、主動(dòng)關(guān)閉 Mesh 等能力：

• 數(shù)據(jù)面故障自動(dòng)容災(zāi)能力：當(dāng) Envoy 異常時(shí)，Naming Agent 會(huì)自動(dòng)返回 Server 實(shí)際的實(shí)例列表，此時(shí)，Client 會(huì)自動(dòng)回退為非 Mesh 劫持模式。

• 主動(dòng)關(guān)閉 Mesh 劫持：用戶也可以主動(dòng)關(guān)閉 Mesh 劫持，此時(shí)，Client 也會(huì)自動(dòng)回退為非 Mesh 劫持模式。

至此，Envoy 能夠劫持 Outbound 流量，但是，只有 Outbound 流量劫持能力的 Envoy 是不完整的，對(duì)于入口限流等功能，還需要具備 Inbound 流量劫持的能力。

Inbound 流量劫持

Inbound 流量主要來自其他機(jī)器，我們無法再依賴單機(jī)的 Naming Agent 偽造地址，得另尋出路。還是基于 Naming 系統(tǒng)的思路，EnvoyS 和 Server 是同機(jī)部署的，他們對(duì)外提供的地址，唯一的區(qū)別在于端口，因此，只要我們能更換 EnvoyC 訪問 Server 時(shí)的端口，就能將 Inbound 流量劫持到 EnvoyS。

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

1. 控制面（Istio）將 EnvoyS 的 IngressPort 作為 Server 的端口下發(fā)給 EnvoyC；

2. EnvoyC 將訪問 Server 的流量轉(zhuǎn)發(fā)到 IngressPort，被 EnvoyS 收到。

3. EnvoyS 再將流量轉(zhuǎn)發(fā)到 Server 服務(wù)端口 NamedPort。

至此，Envoy 具備了部分 Inbound 流量劫持能力，為什么說是部分呢，因?yàn)檫@種機(jī)制無法劫持入口服務(wù)的流量。入口服務(wù)的上游（Client）是外部服務(wù)，它的配置不受 Istio 控制，也就無法采用該機(jī)制完成流量劫持，后續(xù)需進(jìn)一步完善該能力。

Inbound 流量劫持中的坑

除了上面提到的問題，Inbound 流量劫持還存在一些坑。我們發(fā)現(xiàn)當(dāng) EnvoyS 劫持了 Inbound 流量后，L3/L4 層通信協(xié)議的部分健康檢查機(jī)制失效。

L3/L4 層通信協(xié)議的主動(dòng)健康檢查部分功能失效

原因：L3/L4 層通信協(xié)議的主動(dòng)健康檢查默認(rèn)是檢查端口存活，當(dāng)流量被劫持到 EnvoyS 后，該功能實(shí)際檢查的是 EnvoyS 的 IngressPort 端口存活，也就無法反饋 Server NamedPort 端口存活情況。

我們目前采用的解決方案是采用兩段式主動(dòng)健康檢查機(jī)制，兩段分別是：

1. Envoy 間健康檢查：EnvoyC 對(duì) EnvoyS 的健康檢查，該健康檢查能夠反饋 EnvoyS 和 Server 的狀態(tài)。

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

L3/L4 層通信 協(xié)議的異常點(diǎn)驅(qū)逐（被動(dòng)健康檢查）功能失效

原因：L3/L4 層通信協(xié)議的異常點(diǎn)驅(qū)逐條件是連接異常，當(dāng)流量被劫持到 EnvoyS 后，該功能實(shí)際上檢查的是 EnvoyC 能否正常的跟 EnvoyS 建立連接，而不是 Server。

我們目前采用的解決方案是完善L3/L4 層通信協(xié)議的驅(qū)逐條件，增加訪問超時(shí)作為驅(qū)逐條件。因此，當(dāng) Server 異常時(shí)，EnvoyC 會(huì)因?yàn)橐恢睙o法得到應(yīng)答，而將該下游標(biāo)記為異常。

 總結(jié)

最后簡單的對(duì)比下上述兩種方案：

基于服務(wù)發(fā)現(xiàn)的流量劫持機(jī)制目前已應(yīng)用在百度App、信息流、百度地圖等業(yè)務(wù)線的數(shù)百個(gè)服務(wù)、數(shù)萬個(gè)實(shí)例上。這種流量劫持機(jī)制能夠減少轉(zhuǎn)發(fā)性能的損耗，具備數(shù)據(jù)面故障自動(dòng)容災(zāi)能力，能夠動(dòng)態(tài)回傳流量治理參數(shù)。但是該機(jī)制也缺失一些能力：無法劫持入口服務(wù)的流量，后續(xù)我們將進(jìn)一步補(bǔ)齊該能力。

“生產(chǎn)環(huán)境的 ServiceMesh 流量劫持怎么搞”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！