TL; DR： 所有 CNI 都按其應有的方式工作，除了 Kube-Router 和 Kube-OVN 之外，Calico（除了自動 MTU 檢測之外）是最好的。
我過去檢查的文章更新（ и ），在測試時，我在 Ubuntu 1.19 上使用 Kubernetes 18.04，並於 2020 年 XNUMX 月更新了 CNI。
在我們深入研究指標之前...
自 2019 年 XNUMX 月以來有哪些新變化？
- 可以在您自己的叢集上進行測試：您可以使用我們的工具在您自己的叢集上執行測試 Kubernetes 網路基準測試:
- 新成員出現了
- 來自 VMware Tanzu
- 來自 alauda.io
- 新場景：目前檢查執行「Pod-to-Pod」網路效能測試，並且新增了新的「Pod-to-Service」腳本，該腳本執行的測試更接近真實條件。 在實踐中，具有 API 的 Pod 與基礎作為服務一起工作，而不是透過 Pod IP 位址（當然，我們在這兩種情況下都會檢查 TCP 和 UDP）。
- 資源消耗：每個測試現在都有自己的資源比較
- 刪除應用程式測試：我們不再進行HTTP、FTP 和SCP 測試，因為我們與社群和CNI 維護人員進行了富有成效的合作，發現由於CNI 啟動延遲（Pod 的前幾秒），TCP 上的iperf 結果與curl 結果之間存在差距。啟動，這在實際情況下並不典型）。
- 開源：所有測試來源（腳本、yml 設定和原始「原始」資料）均可使用
參考測試協議
協議有詳細描述 請注意，本文是關於具有預設核心的 Ubuntu 18.04。
選擇 CNI 進行評估
本次測試的目的是比較使用一個yaml檔案配置的CNI（因此不包括VPP等所有透過腳本安裝的CNI）。
我們選擇的 CNI 進行比較：
- 安特里亞 v.0.9.1
- 印花布 v3.16
- Canal v3.16（Flannel 網路 + Calico 網路策略）
- 纖毛1.8.2
- 法蘭絨0.12.0
- Kube-router 最新 (2020–08–25)
- 編織網2.7.0
為 CNI 配置 MTU
首先我們檢查一下自動MTU偵測對TCP效能的影響：
MTU 對 TCP 效能的影響
使用 UDP 時會發現更大的差距：
MTU 對 UDP 性能的影響
鑑於測試中揭示的巨大性能影響，我們想向所有 CNI 維護者發出一封希望信：請為 CNI 添加自動 MTU 檢測。 您將拯救小貓、獨角獸，甚至是最可愛的一隻：小德沃普。
但是，如果您需要使用不支援自動 MTU 檢測的 CNI，則可以手動配置它以獲得效能。 請注意，這適用於 Calico、Canal 和 WeaveNet。
我向隨行的 CNI 提出一個小小的請求...
CNI 測試：原始數據
在本節中，我們將比較 CNI 與正確的 MTU（自動確定或手動設定）。 這裡的主要目標是在圖表中顯示原始數據。
顏色圖例：
- 灰色 - 樣品（即裸鐵）
- 綠色 - 頻寬高於 9500 Mbps
- 黃色 - 頻寬高於 9000 Mbps
- 橙色 - 頻寬高於 8000 Mbps
- 紅色 - 頻寬低於 8000 Mbps
- 藍色 - 中性（與頻寬無關）
空載資源消耗
首先，檢查集群「睡眠」時的資源消耗。
空載資源消耗
Pod 到 Pod
此場景假設客戶端 Pod 使用其 IP 位址直接連接到伺服器 Pod。
Pod 到 Pod 場景
TCP
Pod-to-Pod TCP 結果和相應的資源消耗：
UDP
Pod-to-Pod UDP 結果和相應的資源消耗：
Pod 到服務
本節與實際用例相關，客戶端 Pod 透過 ClusterIP 服務連接到伺服器 Pod。
Pod 到服務腳本
TCP
Pod-to-Service TCP 結果以及對應的資源消耗：
UDP
Pod-to-Service UDP結果以及對應的資源消耗：
網路政策支持
其中，唯一不支持政治的是Flannel。 所有其他人都正確實施網路策略，包括入站和出站。 做得好！
CNI加密
在檢查的 CNI 中，有一些可以加密 Pod 之間的網路交換：
- Antrea 使用 IPsec
- Calico 用 wireguard
- 使用 IPsec 的 Cilium
- 使用 IPsec 的 WeaveNet
容量
由於剩下的 CNI 較少，我們將所有場景放入一張圖中：
資源消耗
在本節中，我們將評估在 TCP 和 UDP 中處理 Pod 到 Pod 通訊時所使用的資源。 繪製 Pod 到服務圖是沒有意義的，因為它不提供附加資訊。
把它們放在一起
讓我們嘗試重複所有的圖表，我們在這裡引入了一點主觀性，用“vwry fast”、“low”等詞替換實際值。
結論和我的結論
這有點主觀，因為我正在傳達我自己對結果的解釋。
我很高興新的CNI出現了，Antrea表現良好，許多功能甚至在早期版本中就實現了：自動MTU檢測、加密和易於安裝。
如果我們比較效能，除了 Kube-OVN 和 Kube-Router 之外，所有 CNI 都運作良好。 Kube-Router 也無法偵測到 MTU，我沒有在文件中的任何位置找到配置它的方法（ 關於此主題的請求已開放）。
在資源消耗方面，Cilium仍然比其他廠商使用更多的RAM，但製造商顯然是針對大型集群，這顯然與在三節點集群上的測試不一樣。 Kube-OVN 也消耗大量 CPU 和 RAM 資源，但它是基於 Open vSwitch 的年輕 CNI（與 Antrea 一樣，性能更好且消耗更少）。
除了 Flannel 之外，每個人都有網路策略。 他很可能永遠不會支持他們，因為目標比蒸蘿蔔簡單：越輕越好。
此外，除其他外，加密性能也令人驚嘆。 Calico 是最古老的 CNI 之一，但加密是在幾週前才添加的。 他們選擇了wireguard而不是IPsec，簡單地說，它的效果非常好，令人驚嘆，在這部分測試中完全超越了其他CNI。 當然，由於加密而導致資源消耗增加，但所實現的吞吐量是值得的（與排名第二的 Cilium 相比，Calico 在加密測試中顯示出六倍的提升）。 此外，您可以在將 Calico 部署到叢集後隨時啟用wireguard，如果您願意，您也可以短時間或永久停用它。 不過，這非常方便！ 我們提醒您，Calico 目前無法自動偵測 MTU（此功能計劃在未來版本中提供），因此如果您的網路支援巨型幀 (MTU 9000)，請務必設定 MTU。
除此之外，請注意，Cilium 可以加密叢集節點之間（而不僅僅是 Pod 之間）的流量，這對於公共叢集節點非常重要。
作為結論，我建議以下用例：
- 非常小的集群需要 CNI 或我不需要安全性： 與 絨布，最輕最穩定的CNI（他也是最古老的之一，據傳說他是由Homo Kubernautus或Homo Contaitorus發明的）。 您可能也對最巧妙的項目感興趣 ， 查看！
- 常規集群需要 CNI: 印花布 - 您的選擇，但如果需要，請不要忘記配置 MTU。 您可以輕鬆自然地使用網路策略、開啟和關閉加密等。
- （非常）大規模集群需要 CNI：嗯，測試沒有顯示大型叢集的行為，我很樂意進行測試，但我們沒有數百台具有 10Gbps 連接的伺服器。 因此，最好的選擇是在節點上執行修改後的測試，至少使用 Calico 和 Cilium。
來源： www.habr.com