eBPF將取代服務網格中的邊車Sidecars?
服務網格是一個概念,描述了現代雲原生應用程式在通訊、可見性和安全性方面的要求。這個概念的當前實現涉及在每個工作負載或 pod 中執行 sidecar 代理。邊車、側車 sidecar 代理是解決這些需求的一種非常低效的方法。在這篇文章中,我們將研究 sidecar 模型的替代方案,該模型在 eBPF 的幫助下提供高效、低複雜度的透明服務網格。
看看今天服務網格的特性集,可以總結如下:
- 彈性連線:服務間通訊必須能夠跨越雲、叢集和本地等邊界。通訊必須具有彈性和容錯性。
- L7 流量管理:負載平衡、速率限制和彈性必須是 L7 感知的(HTTP、REST、gRPC、WebSocket 等)。
- 基於身份的安全:依靠網路識別符號來實現安全已經不夠了,傳送和接收服務都必須能夠基於身份而不是網路識別符號來相互驗證。
- 可觀察性和跟蹤:跟蹤和指標形式的可觀察性對於理解、監控和排除應用程式穩定性、效能和可用性至關重要。
- 透明性:功能必須以透明的方式提供給應用程式,即無需更改應用程式程式碼。
在早期,服務網格功能通常以庫的形式實現,要求網格中的每個應用程式連結到用應用程式語言框架編寫的庫。類似的事情在網際網路的早期也發生過:回到過去,應用程式過去常常傳送自己的 TCP/IP 堆疊!正如我們將在本文中討論的那樣,服務網格正在演變為核心職責,就像網路堆疊一樣。
今天,服務網格通常使用一種稱為邊車模型的架構來實現。該架構將實現上述功能的程式碼封裝到第 4 層代理中,然後依賴於服務之間的流量被重定向到這個所謂的 sidecar 代理。之所以稱為 sidecar,是因為每個應用程式都附加了一個代理,就像附加到摩托車上的 sidecar。
這種架構的優點是服務不再需要自己實現服務網格功能。如果部署了許多用不同語言編寫的服務,或者您正在執行不可變的 3rd 方應用程式,這將非常有用。
這種模型的缺點是大量的代理、許多額外的網路連線,以及將網路流量饋送到代理的複雜重定向邏輯。最重要的是,可以將哪種型別的網路流量重定向到第 4 層代理也存在限制。代理在它們可以支援的網路協議方面受到限制。
Sidecar注入的成本
如果我們仔細觀察 sidecar 模型,我們會注意到它實際上所有東西都被塞進了 Linux 核心的網路名稱空間中。然而,它比看起來更復雜,需要許多額外的步驟來透明地注入,這種額外的複雜性帶來了延遲和額外資源消耗方面的巨大成本。早期的基準測試表明,這可能會影響高達 3-4 倍的延遲,並且所有代理都需要大量的額外記憶體。我們將在本文稍後將其與基於 eBPF 的模型進行比較時進行研究。
使用 eBPF 解鎖核心服務網格
為什麼我們之前沒有在核心中建立服務網格?有些人半開玩笑地說 kube-proxy 是原始的服務網格,這是有道理的。Kube-proxy 是一個很好的例子,它展示了 Linux 核心在依賴 iptables 實現的基於網路的傳統功能的同時,可以多麼接近地實現服務網格。但是,這還不夠,缺少 L7 上下文。Kube-proxy 專門在網路資料包級別執行。現代應用程式需要 L7 流量管理、跟蹤、身份驗證和額外的可靠性保證。Kube-proxy 無法在網路級別提供此功能。
eBPF 改變了這個等式。它允許動態擴充套件 Linux 核心的功能。我們一直在為 Cilium 使用 eBPF 來構建一個高效的網路、安全性和可觀察性資料路徑,該資料路徑將自身直接嵌入到 Linux 核心中。應用相同的概念,我們也可以在核心級別解決服務網格需求。事實上,Cilium 已經實現了各種必需的概念,例如基於身份的安全性、L3-L7 可觀察性和授權、加密和負載平衡。丟失的部分現在來到 Cilium。您將在本部落格的末尾找到有關如何加入由 Cilium 社群推動的 Cilium 服務網格測試版計劃的詳細資訊。
你們中的一些人可能想知道為什麼 Linux 核心社群不直接解決這些要求。eBPF 具有巨大的優勢。eBPF 程式碼可以在執行時插入到現有的 Linux 核心中,類似於 Linux 核心模組,但與核心模組不同的是,它可以以安全和可移植的方式完成。這允許 eBPF 實現繼續與服務網格社群一起發展。新的核心版本需要數年時間才能交付到使用者手中。eBPF 是使 Linux 核心能夠跟上快速發展的雲原生技術堆疊的關鍵技術。
。。。
詳細點選標題
結論
eBPF是提供原生且高效的服務網格實現的答案。它將使我們擺脫 sidecar 模型,並允許將現有的代理技術整合到現有的核心名稱空間概念中,使它們成為我們每天已經使用的漂亮容器抽象的一部分。最重要的是,eBPF 將能夠解除安裝越來越多的當前由代理執行的功能,以進一步降低開銷和複雜性。通過能夠整合幾乎所有現有的代理,該架構還允許與大多數現有的服務網格控制平面(Istio、SMI、Linkerd 等)整合。這將使 eBPF 的好處可供廣泛的終端使用者使用,同時將資料路徑效率和開銷討論與控制平面方面的問題分離。
相關文章
- eBPF會成為服務網格的未來嗎?eBPF
- 服務網格將更安全:VMware收購Mesh7改變服務網格的遊戲規則遊戲
- KubeCon 2021|使用 eBPF 代替 iptables 優化服務網格資料面效能eBPF優化
- 微服務架構中的服務邊界與服務識別微服務架構
- 容器、服務網格和API閘道器:它始於邊緣API
- 服務網格 Service Mesh
- 服務網格重蹈ESB的覆轍?為什麼需要SMI服務網格介面? - samnewman
- 服務網格(Envoy+Istio)
- 避免使用服務網格的原因? - Reddit
- 微服務是否真的需要服務網格?微服務
- SerCe的部落格:您不需要任何服務網格
- 服務網格:微服務進入2.0時代微服務
- 談談我對服務網格的理解
- Istio 1.2服務網格釋出
- 服務網格仍然很難 - cncf
- 看看服務網格可以做的所有事情
- 愛奇藝在服務網格方向的落地實踐
- 服務網格service mesh 之 Linkerd
- ServiceMesh:服務網格有哪些應用?
- 部落格的服務端服務端
- 服務網格定義企業上雲新路徑! | Forrester X 螞蟻集團 釋出服務網格白皮書REST
- 企業服務匯流排ESB已死! 服務網格上位
- Java後端分散式系統的服務路由:智慧DNS與服務網格Java後端分散式路由DNS
- MIT:未來電動汽車將取代馬路上87%的私家車MIT
- Microsoft 365應用將取代Office應用,成為體驗微軟服務的新中心ROS微軟
- 服務網格的存在意義 -kelseyhightower
- hystrix對比服務網格istio的destinationrule
- Dapr 不是服務網格,只是我長的和他很像
- 服務網格大戰,再見 Istio! - Fossas
- 使用Istio服務網格實現流量映象
- 服務網格istio概念應知應會
- 服務網格|如何使用 Amesh 配置外掛
- 亞馬遜雲服務(AWS)助力豐田互聯中國車聯網服務全面落地亞馬遜
- 服務網格新成員:亞馬遜釋出App Mesh應用網格亞馬遜APP
- 車載乙太網開發諮詢服務
- 社交網路2.0,誰將取代Facebook?
- 服務網格只是另一種形式的虛擬化
- 從零搭建一個基於Istio的服務網格