CNI 基準測驗：Cilium 網路性能分析

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

作者：Thomas Graf

譯者：羅煜、張亮，均來自KubeSphere 團隊

Thomas Graf 是 Cilium 的聯合創始人，同時也是 Cilium 母公司 Isovalent 的 CTO 和聯合創始人，此前 Thomas 曾先后在 Linux 內核的網路、安全和 eBPF 領域從事了 15 年的開發作業，

注：本文已取得作者本人的翻譯授權

大家好！??

隨著越來越多的關鍵負載被遷移到 Kubernetes 上，網路性能基準測驗正在成為選擇 Kubernetes 網路方案的重要參考，在這篇文章中，我們將基于過去幾周進行的大量基準測驗的結果探討 Cilium 的性能特點，應廣大用戶的要求，我們也將展示 Calico 的測驗結果，以便進行直接對比，

除了展示測驗的結果資料外，我們還將對容器網路基準測驗這一課題進行更深入的研究，并探討以下幾個方面的問題：

• 吞吐量基準測驗
• 容器網路是否會增加開銷
• 打破常規：eBPF 主機路由（Host Routing）
• 測量延遲：每秒請求數
• Cilium eBPF 和 Calico eBPF 的 CPU 火焰圖對比
• 新連接處理速率
• WireGuard 與 IPsec 加密開銷對比
• 測驗環境

測驗結果匯總

在詳細分析基準測驗及其資料之前，我們先展示匯總的測驗結論，如果您希望直接了解測驗細節并得出自己的結論，也可以跳過這一節的內容，

• eBPF 起決定性作用：Cilium 在某些方面優于 Calico 的 eBPF 資料路徑（Data Path），例如在 TCP_RR 和 TCP_CRR 基準測驗中觀察到的延遲，此外，更重要的結論是 eBPF 明顯優于 iptables，在允許使用 eBPF 繞過 iptables 的配置環境中，Cilium 和 Calico 的性能都明顯優于不能繞過 iptables 的情況，

  在研究具體細節后，我們發現 Cilium 和 Calico 利用 eBPF 的方式并不完全相同，雖然二者的某些概念是相似的（考慮到開源的性質，這也并不奇怪），CPU 火焰圖顯示 Cilium 利用了額外的背景關系切換節省功能，這或許可以解釋 TCP_RR 和 TCP_CRR 測驗結果的差異，

  總體而言，從基準測驗結果來看，eBPF 無疑是解決云原生需求挑戰的最佳技術，

• 可觀察性、NetworkPolicy 和 Service：對于這個基準測驗，我們把關注的焦點放在二者的共性上，也就是網路，這使得我們可以直接對比節點網路帶來的性能差異，然而，在實際應用中也會需要用到可觀測性、NetworkPolicy 和 Service，在這些方面 Cilium 和 Calico eBPF 資料路徑差異巨大，Cilium 支持一些 Calico eBPF 資料路徑不具備的功能，但即便是 Kubernetes NetworkPolicy 之類的標準功能，Cilium 和 Calico 的實作方式也不一樣，如果我們投入更大的精力測驗在這些更高級的用例中應用 eBPF，我們可能會發現二者在這些方面的性能有顯著差異，然而，限于篇幅本文將不對此作更多的探討，更加深入的研究將留給下一篇文章，

• 對比 WireGuard 和 IPsec：有些令人意外，盡管 WireGuard 在我們的測驗中能夠實作更高的最大吞吐量，但 IPsec 在相同的吞吐量下 CPU 使用效率更高，這很有可能得益于 AES-NI CPU 指令集，該指令集支持卸載 IPsec 的加密作業，但 WireGuard 不能從中受益，當 AES-NI 指令集不可用時，結果就明顯反轉了，

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

吞吐量基準測驗

免責宣告：

基準測驗難度很大，測驗結果很大程度上依賴于運行測驗的硬體環境，除非是在相同的系統上收集的結果，否則不應直接用絕對的數值進行比較，

讓我們從最常見和最明顯的 TCP 吞吐量基準測驗開始，測量運行在不同節點上的容器之間的最大資料傳輸速率，

上圖顯示了單個 TCP 連接可實作的最大吞吐量，最優的幾個配置性能剛好超過了 40 Gbit/s，以上結果由 netperf 的 TCP_STREAM 測驗得出，測驗環境使用了速率為 100 Gbit/s 的網口以確保網卡不會成為瓶頸，由于運行單個 netperf 行程通過單個 TCP 連接傳輸資料，大部分的網路處理是由單個 CPU 核心完成的，這意味著上面的最大吞吐量受到單個核心的可用 CPU 資源限制，因此可以顯示當 CPU 成為瓶頸時每個配置可以實作的吞吐量，本文后面將會進一步擴展測驗，使用更多的 CPU 核心來消除 CPU 資源的限制，

使用高性能 eBPF 實作的吞吐量甚至略高于節點到節點的吞吐量，這令人非常意外，通常普遍認為，相較于節點到節點的網路，容器網路會帶來額外的開銷，我們暫時先把這個疑惑擱置一旁，進一步研究之后再來分析這個問題，

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

TCP_STREAM 基準測驗的結果已經暗示了哪些配置可以最有效地實作高傳輸速率，但我們還是看一下運行基準測驗時系統整體的 CPU 消耗，

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

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

TCP 吞吐量基準測驗的意義

雖然大多數用戶不太可能經常遇到上述的吞吐量水平，但這樣的基準測驗對特定型別的應用程式有重要意義：

• 需要訪問大量資料的 AI/ML 應用程式
• 資料上傳/下載服務（備份服務、虛擬機鏡像、容器鏡像服務等）
• 流媒體服務，特別是 4K+ 解析度的流媒體

在本文后面的章節，我們將繼續深入討論測量延遲：每秒請求數和新連接處理速率，以更好地展示典型微服務作業負載的性能特點，

容器網路是否會增加開銷

在第一個基準測驗的分析中我們提到，與節點網路相比，容器網路會帶來一些額外開銷，這是為什么呢？讓我們從架構的角度來對比這兩種網路模型，

上圖表明容器網路也需要執行節點到節點網路的所有處理流程，并且這些流程都發生在容器的網路命名空間中（深藍色部分），

由于節點網路的處理作業也需要在容器網路命名空間內進行，在容器網路命名空間之外的任何作業本質上都是額外開銷，上圖顯示了使用 Veth 設備時，Linux 路由的網路路徑，如果您使用 Linux 網橋或 OVS，網路模型可能略有不同，但它們基本的開銷點是相同的，

打破常規：eBPF 主機路由（Host-Routing）

在上面的基準測驗中，您也許會疑惑 Cilium eBPF 和 Cilium eBPF 傳統主機路由（Legacy Host Routing）兩種配置的區別，以及為什么原生的 Cilium eBPF 資料路徑會比主機路由快得多，原生的 Cilium eBPF 資料路徑是一種被稱為 eBPF 主機路由的優化資料路徑，如下圖所示：

eBPF 主機路由允許繞過主機命名空間中所有的 iptables 和上層網路堆疊，以及穿過 Veth 對時的一些背景關系切換，以節省資源開銷，網路資料包到達網路介面設備時就被盡早捕獲，并直接傳送到 Kubernetes Pod 的網路命名空間中，在流量出口側，資料包同樣穿過 Veth 對，被 eBPF 捕獲后，直接被傳送到外部網路介面上，eBPF 直接查詢路由表，因此這種優化完全透明，并與系統上運行的所有提供路由分配的服務兼容，關于如何啟用該特性，請參閱調優指南中的 eBPF 主機路由，

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

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

在上文中，我們分析了只涉及一個 CPU 核心的基準測驗結果，接下來我們將放開單核的限制，將 TCP 流并行化以運行多個 netperf 行程，

注意：由于硬體有 32 個執行緒，我們特意選擇了 32 個行程，以確保系統能夠均勻地分配負載，

上圖并沒有提供十分有價值的資訊，僅僅表明如果投入足夠多的 CPU 資源，所有測驗配置都能達到接近 100 Gbit/s 的線速率，然而，從 CPU 資源來看，我們仍然可以發現效率上的差異，

請注意，上圖中的 CPU 使用率涵蓋了全部的 CPU 消耗，包括正在運行的 netperf 行程的消耗，也包括作業負載執行網路 I/O 所需的 CPU 資源，然而，它并不包括應用程式通常需要執行的任何業務邏輯所帶來的 CPU 消耗，

測量延遲：每秒請求數

每秒請求數與吞吐量指標幾乎完全相反，它可以衡量單個 TCP 持久連接上按順序的單位元組往返的傳輸速率，此基準測驗可以體現網路資料包的處理效率，單個網路資料包的延遲越低，每秒可處理的請求就越多，吞吐量和延遲的共同優化通常需要進行權衡，為了獲得最大的吞吐量，較大的緩沖區是理想的選擇，但是較大的緩沖區會導致延遲增加，這一現象被稱為緩沖區膨脹，Cilium 提供了一個稱為帶寬管理器（Bandwidth Manager）的功能，該功能可以自動配置公平佇列，可實作基于最早發出時間的 Pod 速率限制，并為服務器作業負載優化 TCP 堆疊設定，使吞吐量和延遲之間達到最佳平衡，

這個基準測驗經常被忽視，但它對用戶來說通常比想象的重要得多，因為它模擬了一種十分常見的微服務使用模式：使用持久化的 HTTP 或 gRPC 連接在 Service 之間發送請求和回應，

下圖顯示單個 netperf 行程執行 TCP_RR 測驗時，不同配置的性能表現：

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

我們進一步測驗運行 32 個并行的 netperf 行程以利用所有可用的 CPU 核心，可以看到，所有配置的性能都有所提升，然而，與吞吐量測驗不同的是，在本測驗中投入更多的 CPU 資源并不能彌補效率上的欠缺，因為最大處理速率受延遲而非可用 CPU 資源限制，即便網路帶寬成為瓶頸，我們也會看到相同的每秒請求數值，

總體而言，結果非常鼓舞人心，Cilium 可以在我們的測驗系統上通過 eBPF 主機路由實作近 1,000,000 請求每秒的處理速率，

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

總體而言，Cilium eBPF 和 Calico eBPF 的性能基本相同，這是因為它們使用了相同的資料路徑嗎？并不是，并不存在預定義的 eBPF 資料路徑，eBPF 是一種編程語言和運行時引擎，它允許構建資料路徑特性和許多其他特性，Cilium 和 Calico eBPF 資料路徑差異很大，事實上，Cilium 提供了很多 Calico eBPF 不支持的特性，但即使是在與 Linux 網路堆疊的互動上，兩者也有顯著的差異，我們可以通過二者的 CPU 火焰圖來來進一步分析，

Cilium eBPF（接收路徑）

Cilium 的 eBPF 主機路由提供了很好的免背景關系切換的資料傳送途徑（從網卡到應用程式的套接字），這就是為什么在上面的火焰圖中整個接收端路徑能夠很好地匹配到一張火焰圖中，火焰圖也顯示了 eBPF、TCP/IP 和套接字的處理塊，

Calico eBPF（接收路徑）

Calico eBPF 接收端看起來卻不太一樣，雖然有著相同的 eBPF 處理塊執行 eBPF 程式，但 Calico eBPF 接收路徑穿過了額外的 Veth，這在 Cilium eBPF 資料路徑接收端并不需要，

上圖中的處理仍然在主機的背景關系中執行，下面的這火焰圖顯示了 Pod 中被 process_backlog 恢復執行的作業，雖然這與 Cilium 場景下的作業一樣（都是 TCP/IP+套接字資料傳送），但因為穿過了 Veth 從而需要額外的背景關系切換，

如果您希望自己進行更進一步的研究，可以點擊以下鏈接打開互動式的火焰圖 SVG 檔案查看細節：

• Cilium eBPF SVG 火焰圖 - 發送端
• Cilium eBPF SVG 火焰圖 - 接收端
• Calico eBPF SVG 火焰圖 - 發送端
• Calico eBPF SVG 火焰圖 - 接收端

新連接處理速率

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

這個測驗展示了一個接識訓發起大量 TCP 連接的作業負載，典型的應用場景是由一個公開暴露的服務處理大量客戶端請求，例如 L4 代理或服務為外部端點（例如資料抓取器）創建多個連接，這個基準測驗能夠在卸載到硬體的作業最少的情況下盡可能地壓測系統，從而顯示出不同配置的最大性能差異，

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

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

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

當并行運行 32 個進行 TCP_CRR 測驗的 netpert 行程以利用所有 CPU 核心時，我們觀察到了一個非常有意思的現象，

基線配置的連接處理速率顯著下降，基線配置的性能并沒有隨著可用 CPU 資源的增多而進一步提升，盡管連接跟蹤狀態表大小發生了相應變化并且我們確認并沒有發生因連接跟蹤表記錄達到上限而導致的性能降低，我們重復進行了多次相同的測驗，結果仍然相同，當我們手動通過 -j NOTRACK 規則繞過 iptables 連接跟蹤表時，問題立刻解決了，基線配置性能恢復到 200,000 連接每秒，所以很明顯，一旦連接數超過某個閾值，iptables 連接跟蹤表就會開始出現問題，

注意：在這個測驗中，Calico eBPF 資料路徑的測驗結果一直不是很穩定，我們目前還不清楚原因，網路資料包的傳輸也不是很穩定，我們沒有將測驗結果納入考慮，因為測驗結果不一定準確，我們邀請 Calico 團隊和我們一起研究這個問題并重新進行測驗，

鑒于我們使用的是未經修改的標準應用程式來處理請求和傳輸資訊，每秒處理 200,000 連接是一個非常優秀的成績，不過，我們還是看一下 CPU 的消耗，

這個基準測驗結果顯示了不同配置的最大性能差異，為了達到每秒處理 250,000 新連接的目標，整個系統必須消耗 33% 到 90% 的可用資源，

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

WireGuard 與 IPsec 加密開銷對比

可能所有人都會認為 WireGuard 的性能會優于 IPsec，所以我們先測驗 WireGuard 在不同的最大傳輸單元（MTU）下的性能，

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

以下是 CPU 資源的消耗：

上述結果表明在 MTU 相同的情況下，不同配置之間的 CPU 使用率差異很小，因而可以通過優化 MTU 配置獲得最佳性能，我們還對每秒請求數進行了測驗，得到的結果也相同，感興趣的讀者可以參閱 Cilium 檔案的 CNI 性能基準測驗章節，

WireGuard 與 IPsec 對比

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

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

下面繼續測驗當吞吐量達到 10 Gbit/s 時，WireGuard 和 IPsec 在不同的 MTU 配置下的 CPU 使用率，

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

注意：為了實作 IPsec 的高效率，需要使用支持 AES-NI 指令集的硬體來卸載 IPsec 的加密作業，

后續計劃：目前我們還不清楚為什么 IPsec 的高效率沒有帶來更高的吞吐量，使用更多的 CPU 核心也沒有明顯提升性能，這很可能是由于 RSS 不能很好地跨 CPU 核心處理加密流量，因為通常用于哈希和跨 CPU 核心分配流量的 L4 資訊是加密的，無法決議，因此，從哈希的角度來看，所有的連接都是一樣的，因為在測驗中只利用了兩個 IP 地址，

這是否會影響延遲？讓我進一步研究，延遲基準測驗最能準確地描述微服務作業負載的實際狀況，微服務作業負載通常都會使用持久連接來交換請求和回應，

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

測驗環境

以下是我們使用的裸機配置，我們搭建了兩套完全一樣的互相直連的系統，

• CPU：AMD Ryzen 9 3950X，AM4 平臺，3.5 GHz，16 核 32 執行緒
• 主板：X570 Aorus Master，支持 PCIe 4.0 x16
• 記憶體：HyperX Fury DDR4-3200 128 GB，XMP 頻率 3.2 GHz
• 網卡: Intel E810-CQDA2，雙埠，每埠速率 100 Gbit/s，PCIe 4.0 x16
• 作業系統內核: Linux 5.10 LTS（配置為 CONFIG_PREEMPT_NONE）

除非特別說明，所有測驗都使用了標準的 1500 位元組 MTU，雖然 MTU 的值越高，測驗結果的絕對數值會越好，但本文的基準測驗的目的在于比較相對差異，而不是測驗最高或最低性能的絕對數值，

測驗配置

應廣大用戶的要求，我們展示了 Calico 的測驗結果以便進行對比，為了盡可能清晰地進行對比，我們使用了以下配置型別進行測驗：

• 基線配置（節點到節點）：此配置不使用 Kubernetes 或容器，在基準測驗程序中直接在祼機上運行 netperf，通常情況下此配置的性能最優，
• Cilium eBPF： Cilium 版本為 1.9.6 并按照調優指南進行了調優，開啟了 eBPF 主機路由和 kube-proxy 替換，此配置需要作業系統內核版本為 5.10 或以上，此配置與 Calico eBPF 配置對比最具有參照性，我們重點進行了直接路由模式的基準測驗，因為這種模式下性能通常尤為重要，后續我們也會進一步進行隧道模式的相關基準測驗，
• Cilium eBPF（傳統主機路由）：Cilium 版本為 1.9.6，以傳統主機路由的模式運行，使用標準 kube-proxy，支持 4.9 及以下內核版本，此配置與 Calico 配置對比最具有參照性，
• Calico eBPF：Calico 版本為 3.17.3，同時使用了開啟 kube-proxy 替換、連接跟蹤繞過以及 eBPF FIB 查詢的 eBPF 資料路徑，此配置需要作業系統內核版本為 5.3 或以上，此配置與 Cilium eBPF 配置對比最具有參照性，
• Calico: Calico 版本為 3.17.3，使用標準 kube-proxy，支持較低版本的作業系統內核，此配置與 Cilium eBPF（傳統主機路由）配置對比最具有參照性，

復現測驗結果

測驗所用的全部腳本都已經上傳到 GitHub 倉庫 cilium/cilium-perf-networking 中，可用于復現測驗結果，

下一步

我們在性能調優方面已經取得了不少結果，但我們還有許多其他的想法并將進一步優化 Cilium 各方面的性能，

• 可觀察性基準測驗：單純的網路基準測驗是必要的，但是實作可觀察性所需資源的消耗才是真正區分系統高下的領域，無論是對系統安全還是對故障排除來說，可觀察性都是基礎設施的關鍵特性，并且不同系統的可視化資源消耗有很大不同，eBPF 是實作可觀察性的優秀工具，并且 Cilium 的 Hubble 組件也可以從中受益，在本文的基準測驗中，我們禁用了 Hubble 以便測驗結果可以與 Calico 對比，在后續的文章中，我們將對 Hubble 進行基準測驗，以驗證 Hubble 的 CPU 需求并將 Hubble 與其他類似的系統對比，

• Service 和 NetworkPolicy 基準測驗：當前的基準測驗結果并不涉及任何 Service 和 NetworkPolicy，我們沒有對二者進行測驗以控制本文的內容范圍，我們將進一步對使用 NetworkPolicy 的用例進行測驗，除此之外還將對東西向（east-west）和南北向（north-south）的 Service 進行測驗，如果您已經等不及了，Cilium 1.8 的發布博客已經公布了一些基準測驗結果，并且展示了 XDP 和 eBPF 對性能的顯著提升，

  目前，我們仍然對 NetworkPolicy 在 CIDR 規則方面的性能不太滿意，我們當前的架構針對少量復雜的 CIDR 進行了優化，但并沒有覆寫使用 LPM 來實作的一些特例，一些用戶可能希望對單獨 IP 地址的大型放行和阻止串列進行基準測驗，我們會把這個用例放在優先事項中，并且提供基于哈希表的實作，

• 記憶體優化：我們將繼續優化 Cilium 的記憶體占用，Cilium 主要的記憶體占用來自于 eBPF 的 Map 分配，這些是網路處理所需要的內核級資料結構，為了提高效率，eBPF Map 的大小是預先設定的，以便根據配置所需的記憶體量最小，我們目前對這方面并不是很滿意，這將是我們后續版本的重點作業，

• 打破更多的規則：更多地繞過 iptables：我們認為 iptables 應該完全繞過，容器命名空間和系統其他部分仍有優化潛力，我們還會繼續努力加快服務網格的資料路徑應用程式，目前已經有一個利用 Envoy 的 Socket 層重定向的初步版本，請期待這個方面的進展，

• 想法和建議：如果您有其他想法和建議，請告訴我們，例如，您希望我們進行哪些基準測驗或改進？我們非常希望能得到反饋意見，您可以在 Cilium Slack 發表想法或者通過 Twitter 聯系我們，

更多資訊

• 本文的所有結果資料都可以在 Cilium 檔案的 CNI 性能基準測驗章節查閱，我們會持續更新這些資料，
• 調優指南提供了對 Cilium 進行調優的完整教程，
• 有關 Cilium 的更多資訊，請參閱 Cilium 官方檔案，
• 有關 eBPF 的更多資訊，請訪問 eBPF 官方網站，

KubeSphere 社區活動通知

為了跟社區新老朋友們零距離交流，我們將聯合 CNCF 和其他合作伙伴，從五月到七月，在上海、杭州、深圳、成都這四個城市分別為大家帶來技術的交流與碰撞，2021 年繼上海站首次 Meetup 火爆全場之后，我們將依舊延續 KubeSphere and Friends 的主題，于 5 月 29 日杭州為大家帶來 Kubernetes and Cloud Native Meetup，

我們特別定制了 KubeSphere 全套紀念周邊禮品：T恤、馬克杯、紀念徽章、帆布袋、口罩等，除此之外還有各種云原生硬核書籍等你來拿！

怎么樣，心動了么？報名參與即將到來的杭州站即可獲得定制周邊紀念品！

本文由博客一文多發平臺 OpenWrite 發布！

標籤：其他

上一篇：5.29 相約杭州！云原生 Meetup 第二期杭州站開啟報名

下一篇：5.29 杭州站云原生 Meetup，邀您觀看線上同步直播