再見 Sidecars，eBPF 能否扛起新大旗？

語言: CN / TW / HK

時間 2022-09-14 19:00:14 51CTO技術棧

作者 | Shahar Azulay

編譯 | Ethan

策劃 | 雲昭

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

但如果你退後一步想一想，Sidecar 其實並不一定那麼優雅，當微服務規模變得開始臃腫，Sidecar 模式也需要出現革新。

就如同現在的摩托車很少再有邊車一樣。畢竟，之所以被稱為邊車，是指如果你需要攜帶不適合它本身能承載的東西，你可以將其放在摩托車的邊車上。

然而，邊車解決了摩托車容量有限的問題，但同時也大大減慢了行駛速度，並且使操縱變得更加困難。

服務網格的 Sidecar 模式

服務網格是技術堆疊中的一個層，有助於連線、保護和監控分散式應用程式的各個元件。

通常單體應用程式，不會使用服務網格，因為它作為單個程序執行，沒有複雜的依賴關係網路和程序間通訊。但是，當將單體應用遷移到微服務架構時，就會遇到三大難題：

一、必須應對各個離散的微服務之間的相互通訊的挑戰；

二、需要確保微服務事務是安全的；

三、需要一種有效的方法來從每個微服務中收集可觀察性資料。

管理微服務的成本巨大，如果直接在微服務本身的程式碼中檢測和處理這些問題，開發者將花費大量時間在每個微服務中繁瑣地編寫和維護自定義程式碼，以處理連線性、安全性和可觀測性。

服務網格通過提供 集中管理服務 的方式 解決了這個問題。從本質上講，服務網格允許開發人員將管理微服務連線性、安全性和可觀測性所需的大部分工作，“外包”給專用的基礎設施層，而不必在微服務本身內處理這些任務。通過這種方式，服務網格有助於簡化和標準化微服務的管理方式。

當然，服務網格不能直接與微服務對話或整合，這時候“邊車模式”出現了。Sidecar 成為了服務網格與微服務對話的方式。

在 Sidecar 模式下，需要在託管每個微服務的業務邏輯的主應用程式容器之外，部署一個特殊的 Sidecar 容器。Sidecar 託管一個服務網格代理，該代理負責管理微服務。如果在同一個 Pod 中執行 Sidecar 容器和主容器，則二者可以強制執行在服務網格中定義的治理規則。

Sidecar 模式對於管理分散式應用程式中的微服務很有意義，這些應用程式部署為容器並使用 Kubernetes 進行編排。在沒有更好的技術將服務網格連線到單個應用程式容器的情況下，將 Sidecar 容器與實際的微服務一起部署，是一種將服務網格編排到微服務架構中的簡單直接的方法。

Istio 火起來是有原因的

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

來源：istio.io

Istio 通過提供兩個主要元件來實現服務網格：

1、一個數據平面，它依賴於執行 Envoy 代理的 Sidecar 容器來與各個微服務互動。

2、控制平面，作為集中式程序執行，以提供服務發現、強制配置和安全流量。

Istio 的開源性質和對 Kubernetes 友好的設計使該工具成為迄今為止成千上萬的雲原生託管堆疊的核心部分。

依賴 Sidecar 的問題

Istio 和其他依賴 Sidecar 模式的服務網格的確解決了不少實際問題，但同時也埋下了許多問題的種子。Sidecar 並不是一個完美的解決方案，面對大規模的連線、保護和觀察分散式應用程式的管理需求，像 Istio 這樣的服務網格存在兩個關鍵問題： 高資源消耗和低效能 。

資源開銷

在分散式託管環境中，每個微服務旁邊都需要執行一個 Sidecar 容器，會使執行中的容器總數增加一倍。這也就意味著應用程式最終會消耗更多的資源。

除了 Sidecar 容器本身消耗的資源外，編排器還也增加了管理 Sidecar 的負擔。同時，開發者在部署和更新 Sidecar 時也會消耗更多的網路頻寬。

這也就是說，當執行 Sidecar 時會佔用相當一部分的資源，而留給實際應用程式可用的資源就會減少，這可能會在需求高峰期，帶來較低的效能體驗。當然，由於最終將需要更多節點（或具有更高資源分配的昂貴節點）來處理工作負載，託管成本也會隨之攀升。

效能和延遲

除了託管 Sidecar 的成本之外，Sidecar 容器在網路流量流入和流出每個微服務時，都需要將自己介入其中，難免對效能造成拖累。在應用程式接收和響應請求之前，每個資料包都必須通過 Sidecar，這會增加延遲，並可能對使用者體驗產生負面影響。

邊車模式下的 Istio 效能

Sidecar 容器的效能開銷到底如何？讓我們看一下 Istio 本身記錄的相關資料。

Istio 的資料顯示每個 Envoy 代理每 1000 個請求將消耗 0.35 個 vCPU 和 40 MB 記憶體。當然，效能開銷會根據配置 Istio 的確切用途而有所不同（使用的功能越多，開銷就越高）。

因此，如果你有 10 個微服務，並且為每個微服務部署一個 Envoy Sidecar，則需要額外的 3.5 個 vCPU 和 400 MB 記憶體來託管它們。這可以很容易地轉化為相當於額外的 VM 例項來執行 Sidecar。（根據 Istio 的說法，甚至還需要使用額外的 1 個 vCPU 和 1.5 GB 的控制平面。）

另請注意，Istio 表示每個代理容器平均會在第 90 個百分位延遲上增加 2.65 毫秒。這就是說，當你使用 Sidecar 時，響應速度也將如數延遲。

2.65 毫秒看起來很短暫，但在一個每毫秒都很重要的網路世界中，它的破壞性也會極大，尤其是對於需要真正實時執行的應用程式。

基於 eBPF 實現“無邊車”

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

然而，今天，一個更美好的世界已經成為可能——多虧了 eBPF，它可以直接在 Linux 核心中執行超高效、超安全、動態程式碼，而無需處理核心模組或修改核心原始碼。

對於需要服務網格的工程師來說，這意味著，使用 eBPF，傳統上使用 Sidecar 容器實現的微服務治理可以通過 eBPF 程式在核心中處理。由於 eBPF 程式可以在 Kubernetes 叢集中的每個（基於 Linux 的）節點上執行，它們可以直接在核心中管理微服務連線性、安全性和可觀察性，而不必作為單獨的 Sidecar 執行。

這種方法與 Istio 等傳統服務網格相比，非常有優勢：

效能：由於 eBPF 程式消耗最少的資源，與使用 Sidecar 架構相比，它們將顯著降低執行服務網格的開銷。
簡單性：基於 eBPF 的服務網格將消除部署和管理一套 Sidecar 容器的需要。
可見性和控制性：通過直接在核心中執行，eBPF 程式在可以從容器內訪問哪些資料以及可以對它們施加哪些控制方面幾乎具有無限的範圍。在這方面，基於 eBPF 的網格將比那些依賴於邊車容器的網格更強大。

利用 eBPF 來解決傳統服務網格的缺點，是一個相對較新的想法。目前，開發人員越來越關注這一策略，Cilium 已經實施了這一策略。

Cilium：基於 eBPF 加速節點代理模式

eBPF 的美好未來

eBPF 作為服務網格解決方案的“潛力股”，正在成為開發人員在分散式應用程式中處理安全性、可觀察性和管理方式的“明日之星”。它將開發者從 Sidecar 模型中解放出來，並允許將現有的代理技術整合到現有的核心名稱空間概念中，提供了一種原生且高效的服務網格實現正規化。

除了可以更輕鬆地收集豐富的資料以實現可觀察性、併為在容器內和容器之間流動的資料提供必要的安全性之外，eBPF 也可以被用於服務網路的“核心級”創新，能夠解除安裝越來越多當前由代理執行的功能，以一種更簡單、更有效且資源消耗更少的方式，來管理微服務之間的互動。

Sidecar 會消失嗎

不得不說，即便是一直採用“邊車”的 Istio 也認識到了它的侷限性。9 月 7 日，Istio 宣佈了一種新的資料平面模式 Ambient Mesh，該模式的亮點是取消了以 Sidecar 為中心的架構，取而代之的是無 Sidecar 的方法，同時保留了 Istio 的零信任安全、遙測和流量管理的核心功能。

正如 Istio 官方所言：“自創立以來，Istio 架構的關鍵特徵之一就是使用 Sidecar，但 Sidecar 模式並沒有在應用程式和 Istio 資料平面之間提供完美的隔離，這導致侵入性較高、資源利用不足、流量中斷等問題，使用者需要有一個侵入性更低、更容易使用的選擇。”

當然，這並不是說 Istio 或者依賴“邊車模式”的服務網格將退出舞臺。

我們可以想象這樣一個世界：Istio 控制平面仍然存在，但資料平面由 eBPF 程式驅動，而不是在 Sidecar 容器中執行的 Envoy 代理。Istio 為服務發現和配置管理開發了許多強大的技術，這些功能都將在基於 eBPF 的服務網格中保有持久的魅力。

可以預見，“邊車模式”將在未來幾年慢慢過時——就像連線在摩托車上的邊車一樣。那些優先考慮速度和效率的企業和開發者將再度擁抱 eBPF，掙脫 Sidecar 的限制。

參考連結

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

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

直播主題：人工智慧前沿探索 | AISummit

直播時間： 9月14日（週三）18:30

直播簡介：本專題就人工智慧領域多應用場景的前沿技術發展進行討論，多位技術專家以應用位切點進行展開，深入分析人工智慧領域的前沿探索。

點選視訊號卡片，立即預約直播