編譯 | Ethan

策劃 | 云昭

Sidecar 的概念在容器和微服務(wù)的世界中變得如此普遍，以至于很容易將 Sidecar 視為云原生技術(shù)棧中自然、健康的一部分。

但如果你退后一步想一想，Sidecar 其實(shí)并不一定那么優(yōu)雅，當(dāng)微服務(wù)規(guī)模變得開始臃腫，Sidecar 模式也需要出現(xiàn)革新。

就如同現(xiàn)在的摩托車很少再有邊車一樣。畢竟，之所以被稱為邊車，是指如果你需要攜帶不適合它本身能承載的東西，你可以將其放在摩托車的邊車上。然而，邊車解決了摩托車容量有限的問題，但同時(shí)也大大減慢了行駛速度，并且使操縱變得更加困難。

服務(wù)網(wǎng)格的 Sidecar 模式

服務(wù)網(wǎng)格是技術(shù)堆棧中的一個(gè)層，有助于連接、保護(hù)和監(jiān)控分布式應(yīng)用程序的各個(gè)組件。通常單體應(yīng)用程序，不會(huì)使用服務(wù)網(wǎng)格，因?yàn)樗鳛閱蝹€(gè)進(jìn)程運(yùn)行，沒有復(fù)雜的依賴關(guān)系網(wǎng)絡(luò)和進(jìn)程間通信。但是，當(dāng)將單體應(yīng)用遷移到微服務(wù)架構(gòu)時(shí)，就會(huì)遇到三大難題：一、必須應(yīng)對(duì)各個(gè)離散的微服務(wù)之間的相互通信的挑戰(zhàn)；二、需要確保微服務(wù)事務(wù)是安全的；三、需要一種有效的方法來(lái)從每個(gè)微服務(wù)中收集可觀察性數(shù)據(jù)。管理微服務(wù)的成本巨大，如果直接在微服務(wù)本身的代碼中檢測(cè)和處理這些問題，開發(fā)者將花費(fèi)大量時(shí)間在每個(gè)微服務(wù)中繁瑣地編寫和維護(hù)自定義代碼，以處理連接性、安全性和可觀測(cè)性。

服務(wù)網(wǎng)格通過提供集中管理服務(wù)的方式解決了這個(gè)問題。從本質(zhì)上講，服務(wù)網(wǎng)格允許開發(fā)人員將管理微服務(wù)連接性、安全性和可觀測(cè)性所需的大部分工作，“外包”給專用的基礎(chǔ)設(shè)施層，而不必在微服務(wù)本身內(nèi)處理這些任務(wù)。通過這種方式，服務(wù)網(wǎng)格有助于簡(jiǎn)化和標(biāo)準(zhǔn)化微服務(wù)的管理方式。當(dāng)然，服務(wù)網(wǎng)格不能直接與微服務(wù)對(duì)話或集成，這時(shí)候“邊車模式”出現(xiàn)了。Sidecar 成為了服務(wù)網(wǎng)格與微服務(wù)對(duì)話的方式。

在 Sidecar 模式下，需要在托管每個(gè)微服務(wù)的業(yè)務(wù)邏輯的主應(yīng)用程序容器之外，部署一個(gè)特殊的 Sidecar 容器。Sidecar 托管一個(gè)服務(wù)網(wǎng)格代理，該代理負(fù)責(zé)管理微服務(wù)。如果在同一個(gè) Pod 中運(yùn)行 Sidecar 容器和主容器，則二者可以強(qiáng)制執(zhí)行在服務(wù)網(wǎng)格中定義的治理規(guī)則。Sidecar 模式對(duì)于管理分布式應(yīng)用程序中的微服務(wù)很有意義，這些應(yīng)用程序部署為容器并使用 Kubernetes 進(jìn)行編排。在沒有更好的技術(shù)將服務(wù)網(wǎng)格連接到單個(gè)應(yīng)用程序容器的情況下，將 Sidecar 容器與實(shí)際的微服務(wù)一起部署，是一種將服務(wù)網(wǎng)格編排到微服務(wù)架構(gòu)中的簡(jiǎn)單直接的方法。

Istio 火起來(lái)是有原因的

今天有許多服務(wù)網(wǎng)格，比如 Linkerd 和 Traefik。但可能最流行的解決方案是 Istio，這是一種專為以 Kubernetes 為中心的堆棧而設(shè)計(jì)的開源服務(wù)網(wǎng)格。

來(lái)源：istio.io

Istio 通過提供兩個(gè)主要組件來(lái)實(shí)現(xiàn)服務(wù)網(wǎng)格：1、一個(gè)數(shù)據(jù)平面，它依賴于運(yùn)行 Envoy 代理的 Sidecar 容器來(lái)與各個(gè)微服務(wù)交互。2、控制平面，作為集中式進(jìn)程運(yùn)行，以提供服務(wù)發(fā)現(xiàn)、強(qiáng)制配置和安全流量。

Istio 的開源性質(zhì)和對(duì) Kubernetes 友好的設(shè)計(jì)使該工具成為迄今為止成千上萬(wàn)的云原生托管堆棧的核心部分。?

依賴 Sidecar 的問題

Istio 和其他依賴 Sidecar 模式的服務(wù)網(wǎng)格的確解決了不少實(shí)際問題，但同時(shí)也埋下了許多問題的種子。Sidecar 并不是一個(gè)完美的解決方案，面對(duì)大規(guī)模的連接、保護(hù)和觀察分布式應(yīng)用程序的管理需求，像 Istio 這樣的服務(wù)網(wǎng)格存在兩個(gè)關(guān)鍵問題：高資源消耗和低性能。

1.資源開銷

在分布式托管環(huán)境中，每個(gè)微服務(wù)旁邊都需要運(yùn)行一個(gè) Sidecar 容器，會(huì)使運(yùn)行中的容器總數(shù)增加一倍。這也就意味著應(yīng)用程序最終會(huì)消耗更多的資源。

除了 Sidecar 容器本身消耗的資源外，編排器還也增加了管理 Sidecar 的負(fù)擔(dān)。同時(shí)，開發(fā)者在部署和更新 Sidecar 時(shí)也會(huì)消耗更多的網(wǎng)絡(luò)帶寬。

這也就是說，當(dāng)運(yùn)行 Sidecar 時(shí)會(huì)占用相當(dāng)一部分的資源，而留給實(shí)際應(yīng)用程序可用的資源就會(huì)減少，這可能會(huì)在需求高峰期，帶來(lái)較低的性能體驗(yàn)。當(dāng)然，由于最終將需要更多節(jié)點(diǎn)（或具有更高資源分配的昂貴節(jié)點(diǎn)）來(lái)處理工作負(fù)載，托管成本也會(huì)隨之攀升。

2.性能和延遲

除了托管 Sidecar 的成本之外，Sidecar 容器在網(wǎng)絡(luò)流量流入和流出每個(gè)微服務(wù)時(shí)，都需要將自己介入其中，難免對(duì)性能造成拖累。在應(yīng)用程序接收和響應(yīng)請(qǐng)求之前，每個(gè)數(shù)據(jù)包都必須通過 Sidecar，這會(huì)增加延遲，并可能對(duì)用戶體驗(yàn)產(chǎn)生負(fù)面影響。

邊車模式下的 Istio 性能

Sidecar 容器的性能開銷到底如何？讓我們看一下 Istio 本身記錄的相關(guān)數(shù)據(jù)。Istio 的數(shù)據(jù)顯示每個(gè) Envoy 代理每 1000 個(gè)請(qǐng)求將消耗 0.35 個(gè) vCPU 和 40 MB 內(nèi)存。當(dāng)然，性能開銷會(huì)根據(jù)配置 Istio 的確切用途而有所不同（使用的功能越多，開銷就越高）。

因此，如果你有 10 個(gè)微服務(wù)，并且為每個(gè)微服務(wù)部署一個(gè) Envoy Sidecar，則需要額外的 3.5 個(gè) vCPU 和 400 MB 內(nèi)存來(lái)托管它們。這可以很容易地轉(zhuǎn)化為相當(dāng)于額外的 VM 實(shí)例來(lái)運(yùn)行 Sidecar。（根據(jù) Istio 的說法，甚至還需要使用額外的 1 個(gè) vCPU 和 1.5 GB 的控制平面。）另請(qǐng)注意，Istio 表示每個(gè)代理容器平均會(huì)在第 90 個(gè)百分位延遲上增加 2.65 毫秒。這就是說，當(dāng)你使用 Sidecar 時(shí)，響應(yīng)速度也將如數(shù)延遲。

2.65 毫秒看起來(lái)很短暫，但在一個(gè)每毫秒都很重要的網(wǎng)絡(luò)世界中，它的破壞性也會(huì)極大，尤其是對(duì)于需要真正實(shí)時(shí)執(zhí)行的應(yīng)用程序。?

基于 eBPF 實(shí)現(xiàn)“無(wú)邊車”

開發(fā)人員和 IT 團(tuán)隊(duì)通常將 Sidecar 容器所產(chǎn)生的性能和延遲成本視為必要的弊端。使用帶有 Sidecar 模式的服務(wù)網(wǎng)格比不使用服務(wù)網(wǎng)格要容易得多，并且必須在每個(gè)微服務(wù)中進(jìn)行管理，因此他們很樂意為托管支付更多費(fèi)用和/或接受性能損失，以便在其中集中微服務(wù)管理服務(wù)網(wǎng)格。

然而，今天，一個(gè)更美好的世界已經(jīng)成為可能——多虧了 eBPF，它可以直接在 Linux 內(nèi)核中運(yùn)行超高效、超安全、動(dòng)態(tài)代碼，而無(wú)需處理內(nèi)核模塊或修改內(nèi)核源代碼。

對(duì)于需要服務(wù)網(wǎng)格的工程師來(lái)說，這意味著，使用 eBPF，傳統(tǒng)上使用 Sidecar 容器實(shí)現(xiàn)的微服務(wù)治理可以通過 eBPF 程序在內(nèi)核中處理。由于 eBPF 程序可以在 Kubernetes 集群中的每個(gè)（基于 Linux 的）節(jié)點(diǎn)上運(yùn)行，它們可以直接在內(nèi)核中管理微服務(wù)連接性、安全性和可觀察性，而不必作為單獨(dú)的 Sidecar 運(yùn)行。這種方法與 Istio 等傳統(tǒng)服務(wù)網(wǎng)格相比，非常有優(yōu)勢(shì)：

• 性能：由于 eBPF 程序消耗最少的資源，與使用 Sidecar 架構(gòu)相比，它們將顯著降低運(yùn)行服務(wù)網(wǎng)格的開銷。
• 簡(jiǎn)單性：基于 eBPF 的服務(wù)網(wǎng)格將消除部署和管理一套 Sidecar 容器的需要。
• 可見性和控制性：通過直接在內(nèi)核中運(yùn)行，eBPF 程序在可以從容器內(nèi)訪問哪些數(shù)據(jù)以及可以對(duì)它們施加哪些控制方面幾乎具有無(wú)限的范圍。在這方面，基于 eBPF 的網(wǎng)格將比那些依賴于邊車容器的網(wǎng)格更強(qiáng)大。

利用 eBPF 來(lái)解決傳統(tǒng)服務(wù)網(wǎng)格的缺點(diǎn)，是一個(gè)相對(duì)較新的想法。目前，開發(fā)人員越來(lái)越關(guān)注這一策略，Cilium 已經(jīng)實(shí)施了這一策略。

Cilium：基于 eBPF 加速節(jié)點(diǎn)代理模式

eBPF 的美好未來(lái)

eBPF 作為服務(wù)網(wǎng)格解決方案的“潛力股”，正在成為開發(fā)人員在分布式應(yīng)用程序中處理安全性、可觀察性和管理方式的“明日之星”。它將開發(fā)者從 Sidecar 模型中解放出來(lái)，并允許將現(xiàn)有的代理技術(shù)集成到現(xiàn)有的內(nèi)核命名空間概念中，提供了一種原生且高效的服務(wù)網(wǎng)格實(shí)現(xiàn)范式。

除了可以更輕松地收集豐富的數(shù)據(jù)以實(shí)現(xiàn)可觀察性、并為在容器內(nèi)和容器之間流動(dòng)的數(shù)據(jù)提供必要的安全性之外，eBPF 也可以被用于服務(wù)網(wǎng)絡(luò)的“內(nèi)核級(jí)”創(chuàng)新，能夠卸載越來(lái)越多當(dāng)前由代理執(zhí)行的功能，以一種更簡(jiǎn)單、更有效且資源消耗更少的方式，來(lái)管理微服務(wù)之間的交互。

Sidecar 會(huì)消失嗎

不得不說，即便是一直采用“邊車”的 Istio 也認(rèn)識(shí)到了它的局限性。9 月 7 日，Istio 宣布了一種新的數(shù)據(jù)平面模式 Ambient Mesh，該模式的亮點(diǎn)是取消了以 Sidecar 為中心的架構(gòu)，取而代之的是無(wú) Sidecar 的方法，同時(shí)保留了 Istio 的零信任安全、遙測(cè)和流量管理的核心功能。

正如 Istio 官方所言：“自創(chuàng)立以來(lái)，Istio 架構(gòu)的關(guān)鍵特征之一就是使用 Sidecar，但 Sidecar 模式并沒有在應(yīng)用程序和 Istio 數(shù)據(jù)平面之間提供完美的隔離，這導(dǎo)致侵入性較高、資源利用不足、流量中斷等問題，用戶需要有一個(gè)侵入性更低、更容易使用的選擇?！碑?dāng)然，這并不是說 Istio 或者依賴“邊車模式”的服務(wù)網(wǎng)格將退出舞臺(tái)。我們可以想象這樣一個(gè)世界：Istio 控制平面仍然存在，但數(shù)據(jù)平面由 eBPF 程序驅(qū)動(dòng)，而不是在 Sidecar 容器中運(yùn)行的 Envoy 代理。Istio 為服務(wù)發(fā)現(xiàn)和配置管理開發(fā)了許多強(qiáng)大的技術(shù)，這些功能都將在基于 eBPF 的服務(wù)網(wǎng)格中保有持久的魅力。可以預(yù)見，“邊車模式”將在未來(lái)幾年慢慢過時(shí)——就像連接在摩托車上的邊車一樣。那些優(yōu)先考慮速度和效率的企業(yè)和開發(fā)者將再度擁抱 eBPF，掙脫 Sidecar 的限制。

參考鏈接

https://www.groundcover.com/blog/istio-service-mesh

https://isovalent.com/blog/post/2021-12-08-ebpf-servicemesh

https://istio.io/latest/blog/2022/introducing-ambient-mesh/