作者：Thomas Graf
譯者：羅煜、張亮，均來自 KubeSphere 團隊
Thomas Graf 是 Cilium 的聯(lián)合創(chuàng)始人，同時也是 Cilium 母公司 Isovalent^[1] 的 CTO 和聯(lián)合創(chuàng)始人。此前 Thomas 曾先后在 Linux 內(nèi)核^[2]的網(wǎng)絡(luò)、安全和 eBPF 領(lǐng)域從事了 15 年的開發(fā)工作。

注：本文已取得作者本人的翻譯授權(quán)！

大家好！??

隨著越來越多的關(guān)鍵負(fù)載被遷移到 Kubernetes 上，網(wǎng)絡(luò)性能基準(zhǔn)測試正在成為選擇 Kubernetes 網(wǎng)絡(luò)方案的重要參考。在這篇文章中，我們將基于過去幾周進行的大量基準(zhǔn)測試的結(jié)果探討 Cilium 的性能特點。應(yīng)廣大用戶的要求，我們也將展示 Calico 的測試結(jié)果，以便進行直接對比。

除了展示測試的結(jié)果數(shù)據(jù)外，我們還將對容器網(wǎng)絡(luò)基準(zhǔn)測試這一課題進行更深入的研究，并探討以下幾個方面的問題：

• 吞吐量基準(zhǔn)測試
• 容器網(wǎng)絡(luò)是否會增加開銷
• 打破常規(guī)：eBPF 主機路由（Host Routing）
• 測量延遲：每秒請求數(shù)
• Cilium eBPF 和 Calico eBPF 的 CPU 火焰圖對比
• 新連接處理速率
• WireGuard 與 IPsec 加密開銷對比
• 測試環(huán)境

測試結(jié)果匯總

在詳細(xì)分析基準(zhǔn)測試及其數(shù)據(jù)之前，我們先展示匯總的測試結(jié)論。如果您希望直接了解測試細(xì)節(jié)并得出自己的結(jié)論，也可以跳過這一節(jié)的內(nèi)容。

• eBPF 起決定性作用：Cilium 在某些方面優(yōu)于 Calico 的 eBPF 數(shù)據(jù)路徑（Data Path），例如在 TCP_RR 和 TCP_CRR 基準(zhǔn)測試中觀察到的延遲。此外，更重要的結(jié)論是 eBPF 明顯優(yōu)于 iptables。在允許使用 eBPF 繞過 iptables 的配置環(huán)境中，Cilium 和 Calico 的性能都明顯優(yōu)于不能繞過 iptables 的情況。

  在研究具體細(xì)節(jié)后，我們發(fā)現(xiàn) Cilium 和 Calico 利用 eBPF 的方式并不完全相同。雖然二者的某些概念是相似的（考慮到開源的性質(zhì)，這也并不奇怪），CPU 火焰圖顯示 Cilium 利用了額外的上下文切換節(jié)省功能。這或許可以解釋 TCP_RR 和 TCP_CRR 測試結(jié)果的差異。

  總體而言，從基準(zhǔn)測試結(jié)果來看，eBPF 無疑是解決云原生需求挑戰(zhàn)的最佳技術(shù)。

• 可觀測性、NetworkPolicy 和 Service：對于這個基準(zhǔn)測試，我們把關(guān)注的焦點放在二者的共性上，也就是網(wǎng)絡(luò)。這使得我們可以直接對比節(jié)點網(wǎng)絡(luò)帶來的性能差異。然而，在實際應(yīng)用中也會需要用到可觀測性、NetworkPolicy 和 Service，在這些方面 Cilium 和 Calico eBPF 數(shù)據(jù)路徑差異巨大。Cilium 支持一些 Calico eBPF 數(shù)據(jù)路徑不具備的功能，但即便是 Kubernetes NetworkPolicy 之類的標(biāo)準(zhǔn)功能，Cilium 和 Calico 的實現(xiàn)方式也不一樣。如果我們投入更大的精力測試在這些更高級的用例中應(yīng)用 eBPF，我們可能會發(fā)現(xiàn)二者在這些方面的性能有顯著差異。然而，限于篇幅本文將不對此作更多的探討，更加深入的研究將留給下一篇文章。

• 對比 WireGuard 和 IPsec：有些令人意外，盡管 WireGuard 在我們的測試中能夠?qū)崿F(xiàn)更高的最大吞吐量，但 IPsec 在相同的吞吐量下 CPU 使用效率更高。這很有可能得益于 AES-NI CPU 指令集。該指令集支持卸載 IPsec 的加密工作，但 WireGuard 不能從中受益。當(dāng) AES-NI 指令集不可用時，結(jié)果就明顯反轉(zhuǎn)了。

  好消息是，從 Cilium 1.10 開始，Cilium 不僅支持 IPsec 還支持 WireGuard。您可以選擇其中之一來使用。

吞吐量基準(zhǔn)測試

免責(zé)聲明：

基準(zhǔn)測試難度很大。測試結(jié)果很大程度上依賴于運行測試的硬件環(huán)境。除非是在相同的系統(tǒng)上收集的結(jié)果，否則不應(yīng)直接用絕對的數(shù)值進行比較。

讓我們從最常見和最明顯的 TCP 吞吐量基準(zhǔn)測試開始，測量運行在不同節(jié)點上的容器之間的最大數(shù)據(jù)傳輸速率。

上圖顯示了單個 TCP 連接可實現(xiàn)的最大吞吐量，最優(yōu)的幾個配置性能剛好超過了 40 Gbit/s。以上結(jié)果由 netperf 的 TCP_STREAM 測試得出，測試環(huán)境使用了速率為 100 Gbit/s 的網(wǎng)口以確保網(wǎng)卡不會成為瓶頸。由于運行單個 netperf 進程通過單個 TCP 連接傳輸數(shù)據(jù)，大部分的網(wǎng)絡(luò)處理是由單個 CPU 核心完成的。這意味著上面的最大吞吐量受到單個核心的可用 CPU 資源限制，因此可以顯示當(dāng) CPU 成為瓶頸時每個配置可以實現(xiàn)的吞吐量。本文后面將會進一步擴展測試，使用更多的 CPU 核心來消除 CPU 資源的限制。

使用高性能 eBPF 實現(xiàn)的吞吐量甚至略高于節(jié)點到節(jié)點的吞吐量。這令人非常意外。通常普遍認(rèn)為，相較于節(jié)點到節(jié)點的網(wǎng)絡(luò)，容器網(wǎng)絡(luò)會帶來額外的開銷。我們暫時先把這個疑惑擱置一旁，進一步研究之后再來分析這個問題。

100 Gbit/s 傳輸速率所需的 CPU 資源

TCP_STREAM 基準(zhǔn)測試的結(jié)果已經(jīng)暗示了哪些配置可以最有效地實現(xiàn)高傳輸速率，但我們還是看一下運行基準(zhǔn)測試時系統(tǒng)整體的 CPU 消耗。

上圖顯示了達(dá)到 100 Gbit/s 吞吐量整個系統(tǒng)所需的 CPU 使用率。請注意，這不同于前一個圖中吞吐量對應(yīng)的 CPU 消耗。在上圖中，所有的 CPU 使用率都已折算為傳輸速率穩(wěn)定在 100 Gbit/s 時的數(shù)值以便可以直接對比。上圖中的條形圖越短，對應(yīng)的配置在 100 Gbit/s 傳輸速率時的效率越高。

注意：TCP 流的性能通常受到接收端的限制，因為發(fā)送端可以同時使用 TSO 大包。這可以從上述測試中服務(wù)器側(cè)增加的 CPU 開銷中觀察到。

TCP 吞吐量基準(zhǔn)測試的意義

雖然大多數(shù)用戶不太可能經(jīng)常遇到上述的吞吐量水平，但這樣的基準(zhǔn)測試對特定類型的應(yīng)用程序有重要意義：

• 需要訪問大量數(shù)據(jù)的 AI/ML 應(yīng)用程序
• 數(shù)據(jù)上傳/下載服務(wù)（備份服務(wù)、虛擬機鏡像、容器鏡像服務(wù)等）
• 流媒體服務(wù)，特別是 4K+ 分辨率的流媒體

在本文后面的章節(jié)，我們將繼續(xù)深入討論測量延遲：每秒請求數(shù)^[3]和新連接處理速率^[4]，以更好地展示典型微服務(wù)工作負(fù)載的性能特點。

容器網(wǎng)絡(luò)是否會增加開銷

在第一個基準(zhǔn)測試的分析中我們提到，與節(jié)點網(wǎng)絡(luò)相比，容器網(wǎng)絡(luò)會帶來一些額外開銷。這是為什么呢？讓我們從架構(gòu)的角度來對比這兩種網(wǎng)絡(luò)模型。

上圖表明容器網(wǎng)絡(luò)也需要執(zhí)行節(jié)點到節(jié)點網(wǎng)絡(luò)的所有處理流程，并且這些流程都發(fā)生在容器的網(wǎng)絡(luò)命名空間中（深藍(lán)色部分）。

由于節(jié)點網(wǎng)絡(luò)的處理工作也需要在容器網(wǎng)絡(luò)命名空間內(nèi)進行，在容器網(wǎng)絡(luò)命名空間之外的任何工作本質(zhì)上都是額外開銷。上圖顯示了使用 Veth 設(shè)備時，Linux 路由的網(wǎng)絡(luò)路徑。如果您使用 Linux 網(wǎng)橋或 OVS，網(wǎng)絡(luò)模型可能略有不同，但它們基本的開銷點是相同的。

打破常規(guī)：eBPF 主機路由（Host-Routing）

在上面的基準(zhǔn)測試中，您也許會疑惑 Cilium eBPF 和 Cilium eBPF 傳統(tǒng)主機路由（Legacy Host Routing）兩種配置的區(qū)別，以及為什么原生的 Cilium eBPF 數(shù)據(jù)路徑會比主機路由快得多。原生的 Cilium eBPF 數(shù)據(jù)路徑是一種被稱為 eBPF 主機路由的優(yōu)化數(shù)據(jù)路徑，如下圖所示：

eBPF 主機路由允許繞過主機命名空間中所有的 iptables 和上層網(wǎng)絡(luò)棧，以及穿過 Veth 對時的一些上下文切換，以節(jié)省資源開銷。網(wǎng)絡(luò)數(shù)據(jù)包到達(dá)網(wǎng)絡(luò)接口設(shè)備時就被盡早捕獲，并直接傳送到 Kubernetes Pod 的網(wǎng)絡(luò)命名空間中。在流量出口側(cè)，數(shù)據(jù)包同樣穿過 Veth 對，被 eBPF 捕獲后，直接被傳送到外部網(wǎng)絡(luò)接口上。eBPF 直接查詢路由表，因此這種優(yōu)化完全透明，并與系統(tǒng)上運行的所有提供路由分配的服務(wù)兼容。關(guān)于如何啟用該特性，請參閱調(diào)優(yōu)指南中的 eBPF 主機路由^[5]。

Calico eBPF 正在將一些類似的繞過方法用于 iptables，但這與 Cilium 的原理并不完全相同，文章后面會進一步介紹。不管如何，測試結(jié)果證明繞過緩慢的內(nèi)核子系統(tǒng)（例如 iptables）可以帶來極大的性能提升。

逼近 100 Gbit/s 的線速率（Line Rate）

在上文中，我們分析了只涉及一個 CPU 核心的基準(zhǔn)測試結(jié)果。接下來我們將放開單核的限制，將 TCP 流并行化以運行多個 netperf 進程。

注意：由于硬件有 32 個線程，我們特意選擇了 32 個進程，以確保系統(tǒng)能夠均勻地分配負(fù)載。

上圖并沒有提供十分有價值的信息，僅僅表明如果投入足夠多的 CPU 資源，所有測試配置都能達(dá)到接近 100 Gbit/s 的線速率。然而，從 CPU 資源來看，我們?nèi)匀豢梢园l(fā)現(xiàn)效率上的差異。

請注意，上圖中的 CPU 使用率涵蓋了全部的 CPU 消耗，包括正在運行的 netperf 進程的消耗，也包括工作負(fù)載執(zhí)行網(wǎng)絡(luò) I/O 所需的 CPU 資源。然而，它并不包括應(yīng)用程序通常需要執(zhí)行的任何業(yè)務(wù)邏輯所帶來的 CPU 消耗。

測量延遲：每秒請求數(shù)

每秒請求數(shù)與吞吐量指標(biāo)幾乎完全相反。它可以衡量單個 TCP 持久連接上按順序的單字節(jié)往返的傳輸速率。此基準(zhǔn)測試可以體現(xiàn)網(wǎng)絡(luò)數(shù)據(jù)包的處理效率。單個網(wǎng)絡(luò)數(shù)據(jù)包的延遲越低，每秒可處理的請求就越多。吞吐量和延遲的共同優(yōu)化通常需要進行權(quán)衡。為了獲得最大的吞吐量，較大的緩沖區(qū)是理想的選擇，但是較大的緩沖區(qū)會導(dǎo)致延遲增加。這一現(xiàn)象被稱為緩沖區(qū)膨脹。Cilium 提供了一個稱為帶寬管理器（Bandwidth Manager）^[6]的功能，該功能可以自動配置公平隊列，可實現(xiàn)基于最早發(fā)出時間的 Pod 速率限制，并為服務(wù)器工作負(fù)載優(yōu)化 TCP 棧設(shè)置，使吞吐量和延遲之間達(dá)到最佳平衡。

這個基準(zhǔn)測試經(jīng)常被忽視，但它對用戶來說通常比想象的重要得多，因為它模擬了一種十分常見的微服務(wù)使用模式：使用持久化的 HTTP 或 gRPC 連接在 Service 之間發(fā)送請求和響應(yīng)。

下圖顯示單個 netperf 進程執(zhí)行 TCP_RR 測試時，不同配置的性能表現(xiàn)：

在這個測試中表現(xiàn)更好的配置也實現(xiàn)了更低的平均延遲。然而，這并不足以讓我們對 P95 或 P99 延遲得出結(jié)論。我們將在未來的博客文章中探討這些問題。

我們進一步測試運行 32 個并行的 netperf 進程以利用所有可用的 CPU 核心?？梢钥吹剑信渲玫男阅芏加兴嵘?。然而，與吞吐量測試不同的是，在本測試中投入更多的 CPU 資源并不能彌補效率上的欠缺，因為最大處理速率受延遲而非可用 CPU 資源限制。即便網(wǎng)絡(luò)帶寬成為瓶頸，我們也會看到相同的每秒請求數(shù)值。

總體而言，結(jié)果非常鼓舞人心，Cilium 可以在我們的測試系統(tǒng)上通過 eBPF 主機路由實現(xiàn)近 1,000,000 請求每秒的處理速率。

Cilium eBPF 和 Calico eBPF 的 CPU 火焰圖對比

總體而言，Cilium eBPF 和 Calico eBPF 的性能基本相同。這是因為它們使用了相同的數(shù)據(jù)路徑嗎？并不是。并不存在預(yù)定義的 eBPF 數(shù)據(jù)路徑。eBPF 是一種編程語言和運行時引擎，它允許構(gòu)建數(shù)據(jù)路徑特性和許多其他特性。Cilium 和 Calico eBPF 數(shù)據(jù)路徑差異很大。事實上，Cilium 提供了很多 Calico eBPF 不支持的特性。但即使是在與 Linux 網(wǎng)絡(luò)棧的交互上，兩者也有顯著的差異。我們可以通過二者的 CPU 火焰圖來來進一步分析。

Cilium eBPF（接收路徑）

Cilium 的 eBPF 主機路由提供了很好的免上下文切換的數(shù)據(jù)傳送途徑（從網(wǎng)卡到應(yīng)用程序的套接字）。這就是為什么在上面的火焰圖中整個接收端路徑能夠很好地匹配到一張火焰圖中?；鹧鎴D也顯示了 eBPF、TCP/IP 和套接字的處理塊。

Calico eBPF（接收路徑）

Calico eBPF 接收端看起來卻不太一樣。雖然有著相同的 eBPF 處理塊執(zhí)行 eBPF 程序，但 Calico eBPF 接收路徑穿過了額外的 Veth，這在 Cilium eBPF 數(shù)據(jù)路徑接收端并不需要。

上圖中的處理仍然在主機的上下文中執(zhí)行。下面的這火焰圖顯示了 Pod 中被 process_backlog 恢復(fù)執(zhí)行的工作。雖然這與 Cilium 場景下的工作一樣（都是 TCP/IP+套接字?jǐn)?shù)據(jù)傳送），但因為穿過了 Veth 從而需要額外的上下文切換。

如果您希望自己進行更進一步的研究，可以點擊以下鏈接打開交互式的火焰圖 SVG 文件查看細(xì)節(jié)：

• Cilium eBPF SVG 火焰圖 - 發(fā)送端^[7]
• Cilium eBPF SVG 火焰圖 - 接收端^[8]
• Calico eBPF SVG 火焰圖 - 發(fā)送端^[9]
• Calico eBPF SVG 火焰圖 - 接收端^[10]

新連接處理速率

連接處理速率基準(zhǔn)測試基于每秒請求數(shù)的基準(zhǔn)測試，但為每個請求都建立了新的連接。此基準(zhǔn)測試的結(jié)果顯示了使用持久連接和為每個請求創(chuàng)建新連接兩種方式的性能差別。創(chuàng)建新 TCP 連接需要涉及系統(tǒng)中的多個組件，所以這個測試是目前對整個系統(tǒng)壓力最大的測試。通過這個基準(zhǔn)測試，我們可以看到，充分利用系統(tǒng)中大多數(shù)的可用資源是可能的。

這個測試展示了一個接收或發(fā)起大量 TCP 連接的工作負(fù)載。典型的應(yīng)用場景是由一個公開暴露的服務(wù)處理大量客戶端請求，例如 L4 代理或服務(wù)為外部端點（例如數(shù)據(jù)抓取器）創(chuàng)建多個連接。這個基準(zhǔn)測試能夠在卸載到硬件的工作最少的情況下盡可能地壓測系統(tǒng)，從而顯示出不同配置的最大性能差異。

首先，我們運行一個 netperf 進程來進行 TCP_CRR 測試。

在單個進程下不同配置的性能差異已經(jīng)十分巨大，如果使用更多的 CPU 核心差異還將進一步擴大。同時也可以明顯看出，Cilium 再次能夠彌補網(wǎng)絡(luò)命名空間額外開銷造成的性能損失并達(dá)到和基線配置幾乎相同的性能。

后續(xù)計劃：這個 CPU 資源使用率讓我們很驚訝并促使我們在接下來 1.11 的開發(fā)周期做進一步研究。似乎只要涉及到網(wǎng)絡(luò)命名空間的使用，發(fā)送端的資源開銷總是必不可少的。這一開銷在所有涉及網(wǎng)絡(luò)命名空間的配置中都存在，所以很有可能是由 Cilium 和 Calico 都涉及的內(nèi)核數(shù)據(jù)路徑造成的。我們會及時更新這部分研究的進展。

當(dāng)并行運行 32 個進行 TCP_CRR 測試的 netpert 進程以利用所有 CPU 核心時，我們觀察到了一個非常有意思的現(xiàn)象。

基線配置的連接處理速率顯著下降?；€配置的性能并沒有隨著可用 CPU 資源的增多而進一步提升，盡管連接跟蹤狀態(tài)表大小發(fā)生了相應(yīng)變化并且我們確認(rèn)并沒有發(fā)生因連接跟蹤表記錄達(dá)到上限而導(dǎo)致的性能降低。我們重復(fù)進行了多次相同的測試，結(jié)果仍然相同。當(dāng)我們手動通過 -j NOTRACK 規(guī)則繞過 iptables 連接跟蹤表時，問題立刻解決了，基線配置性能恢復(fù)到 200,000 連接每秒。所以很明顯，一旦連接數(shù)超過某個閾值，iptables 連接跟蹤表就會開始出現(xiàn)問題。

注意：在這個測試中，Calico eBPF 數(shù)據(jù)路徑的測試結(jié)果一直不是很穩(wěn)定。我們目前還不清楚原因。網(wǎng)絡(luò)數(shù)據(jù)包的傳輸也不是很穩(wěn)定。我們沒有將測試結(jié)果納入考慮，因為測試結(jié)果不一定準(zhǔn)確。我們邀請 Calico 團隊和我們一起研究這個問題并重新進行測試。

鑒于我們使用的是未經(jīng)修改的標(biāo)準(zhǔn)應(yīng)用程序來處理請求和傳輸信息，每秒處理 200,000 連接是一個非常優(yōu)秀的成績。不過，我們還是看一下 CPU 的消耗。

這個基準(zhǔn)測試結(jié)果顯示了不同配置的最大性能差異。為了達(dá)到每秒處理 250,000 新連接的目標(biāo)，整個系統(tǒng)必須消耗 33% 到 90% 的可用資源。

由于發(fā)送端 CPU 資源消耗一直高于接收端，我們可以確信相同資源下每秒能接收的連接數(shù)要大于每秒能發(fā)起的連接數(shù)。

WireGuard 與 IPsec 加密開銷對比

可能所有人都會認(rèn)為 WireGuard 的性能會優(yōu)于 IPsec，所以我們先測試 WireGuard 在不同的最大傳輸單元（MTU）下的性能。

不同的配置之間有一些差異。值得注意的是，Cilium 與 kube-proxy 的組合比單獨 Cilium 的性能更好。然而，這個性能差異相對較小并且基本可以通過優(yōu)化 MTU 彌補。

以下是 CPU 資源的消耗：

上述結(jié)果表明在 MTU 相同的情況下，不同配置之間的 CPU 使用率差異很小，因而可以通過優(yōu)化 MTU 配置獲得最佳性能。我們還對每秒請求數(shù)進行了測試，得到的結(jié)果也相同。感興趣的讀者可以參閱 Cilium 文檔的 CNI 性能基準(zhǔn)測試^[11]章節(jié)。

WireGuard 與 IPsec 對比

對 Wireguard 和 IPsec 的性能進行比較更加有趣。Cilium 支持 IPsec 已經(jīng)有一段時間了。從 1.10 開始，Cilium 也開始支持 WireGuard。在其他方面相同的情況下，把這兩個加密方案放在一起進行對比，結(jié)果一定會非常有趣。

不出所料，WireGuard 的吞吐量更高，并且在兩種 MTU 配置下，WireGuard 的最大傳輸速率更高。

下面繼續(xù)測試當(dāng)吞吐量達(dá)到 10 Gbit/s 時，WireGuard 和 IPsec 在不同的 MTU 配置下的 CPU 使用率。

雖然 WireGuard 的最大吞吐量更高，但 IPsec 在吞吐量相同的情況下 CPU 開銷更小從而更有效率，這個差異非常巨大。

注意：為了實現(xiàn) IPsec 的高效率，需要使用支持 AES-NI 指令集的硬件來卸載 IPsec 的加密工作。
后續(xù)計劃：目前我們還不清楚為什么 IPsec 的高效率沒有帶來更高的吞吐量。使用更多的 CPU 核心也沒有明顯提升性能。這很可能是由于 RSS 不能很好地跨 CPU 核心處理加密流量，因為通常用于哈希和跨 CPU 核心分配流量的 L4 信息是加密的，無法解析。因此，從哈希的角度來看，所有的連接都是一樣的，因為在測試中只利用了兩個 IP 地址。

這是否會影響延遲？讓我進一步研究。延遲基準(zhǔn)測試最能準(zhǔn)確地描述微服務(wù)工作負(fù)載的實際狀況，微服務(wù)工作負(fù)載通常都會使用持久連接來交換請求和響應(yīng)。

CPU 效率與觀察到的每秒請求數(shù)相符。然而，每個配置總共消耗的 CPU 資源都不是很高。相比 CPU 消耗方面的差異，延遲方面的差異更為顯著。

測試環(huán)境

以下是我們使用的裸機配置。我們搭建了兩套完全一樣的互相直連的系統(tǒng)。

• CPU：AMD Ryzen 9 3950X，AM4 平臺，3.5 GHz，16 核 32 線程
• 主板：X570 Aorus Master，支持 PCIe 4.0 x16
• 內(nèi)存：HyperX Fury DDR4-3200 128 GB，XMP 頻率 3.2 GHz
• 網(wǎng)卡: Intel E810-CQDA2，雙端口，每端口速率 100 Gbit/s，PCIe 4.0 x16
• 操作系統(tǒng)內(nèi)核: Linux 5.10 LTS（配置為 CONFIG_PREEMPT_NONE）

除非特別說明，所有測試都使用了標(biāo)準(zhǔn)的 1500 字節(jié) MTU。雖然 MTU 的值越高，測試結(jié)果的絕對數(shù)值會越好，但本文的基準(zhǔn)測試的目的在于比較相對差異，而不是測試最高或最低性能的絕對數(shù)值。

測試配置

應(yīng)廣大用戶的要求，我們展示了 Calico 的測試結(jié)果以便進行對比。為了盡可能清晰地進行對比，我們使用了以下配置類型進行測試：

• 基線配置（節(jié)點到節(jié)點）：此配置不使用 Kubernetes 或容器，在基準(zhǔn)測試過程中直接在祼機上運行 netperf。通常情況下此配置的性能最優(yōu)。
• Cilium eBPF： Cilium 版本為 1.9.6 并按照調(diào)優(yōu)指南^[12]進行了調(diào)優(yōu)，開啟了 eBPF 主機路由和 kube-proxy 替換。此配置需要操作系統(tǒng)內(nèi)核版本為 5.10 或以上。此配置與 Calico eBPF 配置對比最具有參照性。我們重點進行了直接路由模式的基準(zhǔn)測試，因為這種模式下性能通常尤為重要。后續(xù)我們也會進一步進行隧道模式的相關(guān)基準(zhǔn)測試。
• Cilium eBPF（傳統(tǒng)主機路由）：Cilium 版本為 1.9.6，以傳統(tǒng)主機路由的模式運行，使用標(biāo)準(zhǔn) kube-proxy，支持 4.9 及以下內(nèi)核版本。此配置與 Calico 配置對比最具有參照性。
• Calico eBPF：Calico 版本為 3.17.3，同時使用了開啟 kube-proxy 替換、連接跟蹤繞過以及 eBPF FIB 查詢的 eBPF 數(shù)據(jù)路徑。此配置需要操作系統(tǒng)內(nèi)核版本為 5.3 或以上。此配置與 Cilium eBPF 配置對比最具有參照性。
• Calico: Calico 版本為 3.17.3，使用標(biāo)準(zhǔn) kube-proxy，支持較低版本的操作系統(tǒng)內(nèi)核。此配置與 Cilium eBPF（傳統(tǒng)主機路由）配置對比最具有參照性。

復(fù)現(xiàn)測試結(jié)果

測試所用的全部腳本都已經(jīng)上傳到 GitHub 倉庫 cilium/cilium-perf-networking^[13] 中，可用于復(fù)現(xiàn)測試結(jié)果。

下一步

我們在性能調(diào)優(yōu)方面已經(jīng)取得了不少結(jié)果，但我們還有許多其他的想法并將進一步優(yōu)化 Cilium 各方面的性能。

• 可觀測性基準(zhǔn)測試：單純的網(wǎng)絡(luò)基準(zhǔn)測試是必要的，但是實現(xiàn)可觀測性所需資源的消耗才是真正區(qū)分系統(tǒng)高下的領(lǐng)域。無論是對系統(tǒng)安全還是對故障排除來說，可觀測性都是基礎(chǔ)設(shè)施的關(guān)鍵特性，并且不同系統(tǒng)的可視化資源消耗有很大不同。eBPF 是實現(xiàn)可觀測性的優(yōu)秀工具，并且 Cilium 的 Hubble^[14] 組件也可以從中受益。在本文的基準(zhǔn)測試中，我們禁用了 Hubble 以便測試結(jié)果可以與 Calico 對比。在后續(xù)的文章中，我們將對 Hubble 進行基準(zhǔn)測試，以驗證 Hubble 的 CPU 需求并將 Hubble 與其他類似的系統(tǒng)對比。

• Service 和 NetworkPolicy 基準(zhǔn)測試：當(dāng)前的基準(zhǔn)測試結(jié)果并不涉及任何 Service 和 NetworkPolicy。我們沒有對二者進行測試以控制本文的內(nèi)容范圍。我們將進一步對使用 NetworkPolicy 的用例進行測試，除此之外還將對東西向（east-west）和南北向（north-south）的 Service 進行測試。如果您已經(jīng)等不及了，Cilium 1.8 的發(fā)布博客^[15]已經(jīng)公布了一些基準(zhǔn)測試結(jié)果，并且展示了 XDP 和 eBPF 對性能的顯著提升。

  目前，我們?nèi)匀粚?NetworkPolicy 在 CIDR 規(guī)則方面的性能不太滿意。我們當(dāng)前的架構(gòu)針對少量復(fù)雜的 CIDR 進行了優(yōu)化，但并沒有覆蓋使用 LPM 來實現(xiàn)的一些特例。一些用戶可能希望對單獨 IP 地址的大型放行和阻止列表進行基準(zhǔn)測試。我們會把這個用例放在優(yōu)先事項中，并且提供基于哈希表的實現(xiàn)。

• 內(nèi)存優(yōu)化：我們將繼續(xù)優(yōu)化 Cilium 的內(nèi)存占用。Cilium 主要的內(nèi)存占用來自于 eBPF 的 Map 分配。這些是網(wǎng)絡(luò)處理所需要的內(nèi)核級數(shù)據(jù)結(jié)構(gòu)。為了提高效率，eBPF Map 的大小是預(yù)先設(shè)定的，以便根據(jù)配置所需的內(nèi)存量最小。我們目前對這方面并不是很滿意，這將是我們后續(xù)版本的重點工作。

• 打破更多的規(guī)則：更多地繞過 iptables：我們認(rèn)為 iptables 應(yīng)該完全繞過。容器命名空間和系統(tǒng)其他部分仍有優(yōu)化潛力。我們還會繼續(xù)努力加快服務(wù)網(wǎng)格的數(shù)據(jù)路徑應(yīng)用程序。目前已經(jīng)有一個利用 Envoy 的 Socket 層重定向^[16]的初步版本。請期待這個方面的進展。

• 想法和建議：如果您有其他想法和建議，請告訴我們。例如，您希望我們進行哪些基準(zhǔn)測試或改進？我們非常希望能得到反饋意見。您可以在 Cilium Slack^[17] 發(fā)表想法或者通過 Twitter^[18] 聯(lián)系我們。

更多信息

• 本文的所有結(jié)果數(shù)據(jù)都可以在 Cilium 文檔的 CNI 性能基準(zhǔn)測試^[19]章節(jié)查閱。我們會持續(xù)更新這些數(shù)據(jù)。
• 調(diào)優(yōu)指南^[20]提供了對 Cilium 進行調(diào)優(yōu)的完整教程。
• 有關(guān) Cilium 的更多信息，請參閱 Cilium 官方文檔^[21]。
• 有關(guān) eBPF 的更多信息，請訪問 eBPF 官方網(wǎng)站^[22]。

腳注