編譯 | Ethan

策劃 | 云昭

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

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

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

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

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

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

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

Istio 火起來是有原因的

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

來源：istio.io

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

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

依賴 Sidecar 的問題

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

1.資源開銷

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

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

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

2.性能和延遲

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

邊車模式下的 Istio 性能

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

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

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

基于 eBPF 實現(xiàn)“無邊車”

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

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

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

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

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

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

eBPF 的美好未來

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

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

Sidecar 會消失嗎

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

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