12操逼网站,十八禁网站免费,日本親子亂子偷XXXX50,一区二区三视频,超碰无码人妻,嫩草成人影院,亚洲无码毛片基地,丁香五月婷婷久久

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

原文鏈接：https://cilium.io/blog/2021/05/11/cni-benchmark

大家好！??

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

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

吞吐量基準(zhǔn)測試
容器網(wǎng)絡(luò)是否會(huì)增加開銷
打破常規(guī)：eBPF 主機(jī)路由（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：對于這個(gè)基準(zhǔn)測試，我們把關(guān)注的焦點(diǎn)放在二者的共性上，也就是網(wǎng)絡(luò)。這使得我們可以直接對比節(jié)點(diǎn)網(wǎng)絡(luò)帶來的性能差異。然而，在實(shí)際應(yīng)用中也會(huì)需要用到可觀測性、NetworkPolicy 和 Service，在這些方面 Cilium 和 Calico eBPF 數(shù)據(jù)路徑差異巨大。Cilium 支持一些 Calico eBPF 數(shù)據(jù)路徑不具備的功能，但即便是 Kubernetes NetworkPolicy 之類的標(biāo)準(zhǔn)功能，Cilium 和 Calico 的實(shí)現(xiàn)方式也不一樣。如果我們投入更大的精力測試在這些更高級的用例中應(yīng)用 eBPF，我們可能會(huì)發(fā)現(xiàn)二者在這些方面的性能有顯著差異。然而，限于篇幅本文將不對此作更多的探討，更加深入的研究將留給下一篇文章。
對比 WireGuard 和 IPsec：有些令人意外，盡管 WireGuard 在我們的測試中能夠?qū)崿F(xiàn)更高的最大吞吐量，但 IPsec 在相同的吞吐量下 CPU 使用效率更高。這很有可能得益于 AES-NI CPU 指令集。該指令集支持卸載 IPsec 的加密工作，但 WireGuard 不能從中受益。當(dāng) AES-NI 指令集不可用時(shí)，結(jié)果就明顯反轉(zhuǎn)了。
好消息是，從 Cilium 1.10 開始，Cilium 不僅支持 IPsec 還支持 WireGuard。您可以選擇其中之一來使用。

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

免責(zé)聲明：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我們進(jìn)一步測試運(yùn)行 32 個(gè)并行的 netperf 進(jìn)程以利用所有可用的 CPU 核心?？梢钥吹剑信渲玫男阅芏加兴嵘?。然而，與吞吐量測試不同的是，在本測試中投入更多的 CPU 資源并不能彌補(bǔ)效率上的欠缺，因?yàn)樽畲筇幚硭俾适苎舆t而非可用 CPU 資源限制。即便網(wǎng)絡(luò)帶寬成為瓶頸，我們也會(huì)看到相同的每秒請求數(shù)值。

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

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

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

Cilium eBPF（接收路徑）

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

Calico eBPF（接收路徑）

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

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

如果您希望自己進(jìn)行更進(jìn)一步的研究，可以點(diǎn)擊以下鏈接打開交互式的火焰圖 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)測試，但為每個(gè)請求都建立了新的連接。此基準(zhǔn)測試的結(jié)果顯示了使用持久連接和為每個(gè)請求創(chuàng)建新連接兩種方式的性能差別。創(chuàng)建新 TCP 連接需要涉及系統(tǒng)中的多個(gè)組件，所以這個(gè)測試是目前對整個(gè)系統(tǒng)壓力最大的測試。通過這個(gè)基準(zhǔn)測試，我們可以看到，充分利用系統(tǒng)中大多數(shù)的可用資源是可能的。

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

首先，我們運(yùn)行一個(gè) netperf 進(jìn)程來進(jìn)行 TCP_CRR 測試。

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

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

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

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

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

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

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

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

WireGuard 與 IPsec 加密開銷對比

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

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

以下是 CPU 資源的消耗：

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

WireGuard 與 IPsec 對比

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

bench wireguard ipsec tcp stream 1 stream

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

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

bench wireguard ipsec tcp stream 1 stream cpu

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

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

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

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

bench wireguard ipsec tcp rr 1 process cpu

測試環(huán)境

以下是我們使用的裸機(jī)配置。我們搭建了兩套完全一樣的互相直連的系統(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ù)值會(huì)越好，但本文的基準(zhǔn)測試的目的在于比較相對差異，而不是測試最高或最低性能的絕對數(shù)值。

測試配置

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

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

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

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

下一步

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

可觀測性基準(zhǔn)測試：單純的網(wǎng)絡(luò)基準(zhǔn)測試是必要的，但是實(shí)現(xiàn)可觀測性所需資源的消耗才是真正區(qū)分系統(tǒng)高下的領(lǐng)域。無論是對系統(tǒng)安全還是對故障排除來說，可觀測性都是基礎(chǔ)設(shè)施的關(guān)鍵特性，并且不同系統(tǒng)的可視化資源消耗有很大不同。eBPF 是實(shí)現(xiàn)可觀測性的優(yōu)秀工具，并且 Cilium 的 Hubble^[14] 組件也可以從中受益。在本文的基準(zhǔn)測試中，我們禁用了 Hubble 以便測試結(jié)果可以與 Calico 對比。在后續(xù)的文章中，我們將對 Hubble 進(jìn)行基準(zhǔn)測試，以驗(yàn)證 Hubble 的 CPU 需求并將 Hubble 與其他類似的系統(tǒng)對比。
Service 和 NetworkPolicy 基準(zhǔn)測試：當(dāng)前的基準(zhǔn)測試結(jié)果并不涉及任何 Service 和 NetworkPolicy。我們沒有對二者進(jìn)行測試以控制本文的內(nèi)容范圍。我們將進(jìn)一步對使用 NetworkPolicy 的用例進(jìn)行測試，除此之外還將對東西向（east-west）和南北向（north-south）的 Service 進(jìn)行測試。如果您已經(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 進(jìn)行了優(yōu)化，但并沒有覆蓋使用 LPM 來實(shí)現(xiàn)的一些特例。一些用戶可能希望對單獨(dú) IP 地址的大型放行和阻止列表進(jìn)行基準(zhǔn)測試。我們會(huì)把這個(gè)用例放在優(yōu)先事項(xiàng)中，并且提供基于哈希表的實(shí)現(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ù)版本的重點(diǎn)工作。
打破更多的規(guī)則：更多地繞過 iptables：我們認(rèn)為 iptables 應(yīng)該完全繞過。容器命名空間和系統(tǒng)其他部分仍有優(yōu)化潛力。我們還會(huì)繼續(xù)努力加快服務(wù)網(wǎng)格的數(shù)據(jù)路徑應(yīng)用程序。目前已經(jīng)有一個(gè)利用 Envoy 的 Socket 層重定向^[16]的初步版本。請期待這個(gè)方面的進(jìn)展。
想法和建議：如果您有其他想法和建議，請告訴我們。例如，您希望我們進(jìn)行哪些基準(zhǔn)測試或改進(jìn)？我們非常希望能得到反饋意見。您可以在 Cilium Slack^[17] 發(fā)表想法或者通過 Twitter^[18] 聯(lián)系我們。

Cilium 網(wǎng)絡(luò)性能分析