作者：kaiyun開云創(chuàng)新 KH
目前有幾個(gè)服務(wù)網(wǎng)格產(chǎn)品和項(xiàng)目，有望簡(jiǎn)化應(yīng)用程序微服務(wù)之間的連接。同時(shí)提供附加功能，如安全連接、可觀察性和流量管理。但正如我們?cè)谶^去幾年中反復(fù)看到的那樣，對(duì)服務(wù)網(wǎng)格的興奮已經(jīng)被對(duì)額外的復(fù)雜性和開銷的實(shí)際擔(dān)憂沖淡了。讓我們來看看 EBPF 如何簡(jiǎn)化服務(wù)網(wǎng)格，使服務(wù)網(wǎng)格數(shù)據(jù)平面更高效、更易于部署。
Sidecar 問題
如今，Kubernetes 的服務(wù)網(wǎng)格解決方案要求您將代理 sidecar 容器（如Envoy或Linkerd-Proxy）添加到每個(gè)應(yīng)用程序 Pod。這是正確的：即使在一個(gè)非常小的環(huán)境中，比如說，有20個(gè)服務(wù)，每個(gè)服務(wù)運(yùn)行5個(gè) pod，分布在三個(gè)節(jié)點(diǎn)上，您也有100個(gè)代理容器。無論代理實(shí)現(xiàn)多么小、多么高效，純粹的重復(fù)都會(huì)耗費(fèi)資源。 每個(gè)代理使用的內(nèi)存隨著它需要與之通信的服務(wù)數(shù)量的增加而增加。Pranay Singhal 寫了他配置 Istio 的經(jīng)驗(yàn)，以減少每個(gè)代理大約1GB的消耗（！）到更合理的60-70MB。但是，即使在我們想象的三個(gè)節(jié)點(diǎn)上有100個(gè)代理的小型環(huán)境中，這種優(yōu)化配置仍然需要每個(gè)節(jié)點(diǎn)大約2GB。
為什么我們需要這些 sidecar？此模型允許代理容器與 Pod 中的應(yīng)用程序容器共享網(wǎng)絡(luò)命名空間。網(wǎng)絡(luò)名稱空間是 Linux 內(nèi)核構(gòu)造，它允許容器和 pod 擁有自己獨(dú)立的網(wǎng)絡(luò)堆棧，將集裝箱化應(yīng)用程序彼此隔離。這使得應(yīng)用程序互不干擾，這就是為什么，在端口80上運(yùn)行 Web 應(yīng)用程序時(shí)，您可以擁有任意數(shù)量的 pod —網(wǎng)絡(luò)名稱空間意味著它們都有自己的端口80。代理必須共享相同的網(wǎng)絡(luò)命名空間，以便它可以攔截和處理來自應(yīng)用程序容器的流量。
eBPF
重要的是，每個(gè)節(jié)點(diǎn)只有一個(gè)內(nèi)核；在一個(gè)節(jié)點(diǎn)上運(yùn)行的所有容器（以及所有pod）共享相同的內(nèi)核。如果您將EBPF程序添加到內(nèi)核中的事件，則無論哪個(gè)進(jìn)程導(dǎo)致該事件，無論它是在應(yīng)用程序容器中運(yùn)行還是直接在主機(jī)上運(yùn)行，它都將被觸發(fā)。
這就是為什么 eBPF 對(duì)于 Kubernetes 中的任何類型的工具都是如此令人興奮的技術(shù)—您只需要為每個(gè)節(jié)點(diǎn)添加一次工具，所有的應(yīng)用程序單元都將被覆蓋。無論您是在尋求可觀察性、安全性還是聯(lián)網(wǎng)，基于 EBPF 的解決方案都可以在不需要 Sidecar 的情況下為應(yīng)用程序提供儀表。
基于 eBPF 的 Cilium 項(xiàng)目（最近在孵化階段加入了云計(jì)算基金會(huì)）將這種“無邊”模型引入了服務(wù)網(wǎng)格世界。與傳統(tǒng)的 Sidecar 模型一樣，Cilium 支持每個(gè)節(jié)點(diǎn)使用單個(gè) Envoy 代理實(shí)例來運(yùn)行服務(wù)網(wǎng)格數(shù)據(jù)平面。使用前面的示例，這將代理實(shí)例的數(shù)量從100個(gè)減少到3個(gè)。
更少的 YAML
在 Sidecar 模型中，需要修改指定每個(gè)應(yīng)用程序 Pod 的 YAML 以添加 Sidecar 容器。這通常是自動(dòng)化的——例如，在部署每個(gè)應(yīng)用程序 Pod 時(shí)，使用 Mutating webhook 來注入 sidecar。
例如，在 Istio 中，這需要標(biāo)記 Kubernetes 命名空間和/或pod來定義是否應(yīng)該注入 sidecar ，當(dāng)然這需要為集群?jiǎn)⒂?Mutating webhook。
但如果出了問題怎么辦？如果名稱空間或 pod 的標(biāo)簽不正確，則不會(huì)注入 sidecar，pod 也不會(huì)連接到服務(wù)網(wǎng)格。更糟糕的是，如果攻擊者破壞了集群并能夠運(yùn)行惡意工作負(fù)載（例如加密貨幣礦工），他們將不太可能對(duì)其進(jìn)行標(biāo)記，使其參與服務(wù)網(wǎng)格。通過服務(wù)網(wǎng)格提供的流量可觀察性，它將不可見。
相反，在支持 eBPF 的 Sidecarless 代理模型中，POD 不需要任何額外的 YAML 來進(jìn)行插裝，而是使用 CRD 在集群的基礎(chǔ)上配置服務(wù)網(wǎng)格。即使是預(yù)先存在的 pod 也可以成為服務(wù)網(wǎng)格的一部分，而不需要重新啟動(dòng)。
如果攻擊者試圖通過直接在主機(jī)上運(yùn)行工作負(fù)載來繞過 Kubernetes 編排，eBPF 程序可以看到并控制此活動(dòng)，因?yàn)樗趦?nèi)核中是可見的。
eBPF 的網(wǎng)絡(luò)效率
消除 Sidecar 并不是 eBPF 優(yōu)化服務(wù)網(wǎng)格的唯一方法。支持 EBPF 的網(wǎng)絡(luò)允許數(shù)據(jù)包采用繞過部分內(nèi)核網(wǎng)絡(luò)堆棧的捷徑，這可以顯著提高 Kubernetes 網(wǎng)絡(luò)的性能。讓我們看看這如何應(yīng)用于服務(wù)網(wǎng)格數(shù)據(jù)平面。在服務(wù)網(wǎng)格的情況下，代理作為傳統(tǒng)網(wǎng)絡(luò)中的 Sidecar 運(yùn)行，數(shù)據(jù)包到達(dá)應(yīng)用程序的路徑相當(dāng)曲折：入站數(shù)據(jù)包必須遍歷主機(jī) TCP/IP 堆棧才能到達(dá)POD通過虛擬以太網(wǎng)連接的網(wǎng)絡(luò)命名空間。從那里，數(shù)據(jù)包必須通過 Pod 的網(wǎng)絡(luò)堆棧才能到達(dá)代理，它通過環(huán)回接口將數(shù)據(jù)包轉(zhuǎn)發(fā)到應(yīng)用程序。請(qǐng)記住，流量必須流經(jīng)連接兩端的代理，與非服務(wù)網(wǎng)格流量相比，這導(dǎo)致延遲顯著增加。
基于 eBPF 的 Kubernetes CNI 實(shí)現(xiàn)（如Cilium）可以使用 eBPF 程序，明智地掛接到內(nèi)核中的特定點(diǎn)，以沿著更直接的路由重定向數(shù)據(jù)包。Cilium 知道所有的 Kubernetes 端點(diǎn)和服務(wù)身份，所以這是可行的。當(dāng)數(shù)據(jù)包到達(dá)主機(jī)時(shí)，Cilium 可以將其直接發(fā)送到其目的地的代理或 Pod 端點(diǎn)。
網(wǎng)絡(luò)中的加密
如果網(wǎng)絡(luò)解決方案能夠識(shí)別 Kubernetes 服務(wù)，并在這些服務(wù)的端點(diǎn)之間提供網(wǎng)絡(luò)連接，那么它能夠提供服務(wù)網(wǎng)格數(shù)據(jù)平面的功能也就不足為奇了。但這些功能可以超越基本的連接。一個(gè)例子是透明加密。
通常使用服務(wù)網(wǎng)格來確保所有應(yīng)用程序流量都經(jīng)過身份驗(yàn)證和加密。這是通過雙向 TLS（MTLS）實(shí)現(xiàn)的。服務(wù)網(wǎng)格代理組件充當(dāng)網(wǎng)絡(luò)連接的端點(diǎn)，并與其遠(yuǎn)程對(duì)等體協(xié)商安全TLS連接。此連接對(duì)代理之間的通信進(jìn)行加密，而無需對(duì)應(yīng)用程序進(jìn)行任何更改。
但是，在應(yīng)用層管理的TLS并不是在組件之間實(shí)現(xiàn)身份驗(yàn)證和加密通信的唯一方法。另一種選擇是使用 IPSec或WireGuard 在網(wǎng)絡(luò)層加密流量。由于它工作在網(wǎng)絡(luò)層，這種加密不僅對(duì)應(yīng)用程序而且對(duì)代理都是完全透明的，并且它可以在有或沒有服務(wù)網(wǎng)格的情況下啟用。如果使用服務(wù)網(wǎng)格的唯一原因是提供加密，則可能需要考慮網(wǎng)絡(luò)級(jí)加密。它不僅更簡(jiǎn)單，但它也可用于對(duì)節(jié)點(diǎn)上的任何流量進(jìn)行身份驗(yàn)證和加密—它不僅限于那些啟用了Sidecar的工作負(fù)載。
原文出自 https://thenewstack.io/how-ebpf-streamlines-the-service-mesh/
體驗(yàn)服務(wù)網(wǎng)格SolarMesh，從這里開始
讓企業(yè)都能高效創(chuàng)新
企業(yè)云原生數(shù)字化創(chuàng)新平臺(tái)CloudOS?
可插拔云原生工具集Cloud Native Toolkit
開發(fā)者專屬一站式在線服務(wù)Methodot
