10 Gbps 網路上的 Kubernetes 網路外掛程式 (CNI) 基準測試結果（更新日期：2019 年 XNUMX 月）

這是我的更新 之前的基準，現在運行在 Kubernetes 1.14 上，最新的 CNI 版本截至 2019 年 XNUMX 月。

首先，我要感謝 Cilium 團隊：他們幫我檢查並修正了指標監控腳本。

自 2018 年 XNUMX 月以來發生了什麼變化

以下是自那時以來發生的變化（如果您有興趣的話）：

Flannel 仍然是最快、最簡單的 CNI 接口，但仍然不支援網路策略和加密。

Romana 不再受支持，因此我們已將其從基準測試中刪除。

WeaveNet 現在支援入口和出口的網路策略！ 但生產力卻下降了。

在 Calico 中，您仍然需要手動配置最大資料包大小 (MTU) 以獲得最佳效能。 Calico 提供了兩種安裝 CNI 的選項，因此您無需單獨的 ETCD 儲存庫即可完成：

• 將狀態儲存在 Kubernetes API 中作為資料儲存（叢集大小 < 50 個節點）；
• 使用 Typha 代理將狀態儲存在 Kubernetes API 中作為資料存儲，以減輕 K8S API 上的負載（叢集大小 > 50 個節點）。

Calico 宣布支持 應用層策略 在 Istio 之上實現應用程式級安全性。

Cilium 現在支援加密！ Cilium 透過 IPSec 隧道提供加密，並提供加密 WeaveNet 網路的替代方案。 但啟用加密後，WeaveNet 比 Cilium 更快。

由於內建的 ETCD 操作符，Cilium 現在更容易部署。

Cilium 團隊試圖透過降低記憶體消耗和 CPU 成本來減輕其 CNI 的重量，但其競爭對手的重量仍然更輕。

基準上下文

此基準測試在三台具有 10 Gb Supermicro 交換器的非虛擬化 Supermicro 伺服器上執行。 伺服器透過被動 DAC SFP+ 纜線直接連接到交換機，並使用巨型訊框 (MTU 9000) 配置在同一 VLAN 上。

Kubernetes 1.14.0 使用 Docker 18.04（此版本中的預設 Docker 版本）安裝在 Ubuntu 18.09.2 LTS 上。

為了提高可重複性，我們決定始終在第一個節點上配置主伺服器，將基準測試的伺服器部分放在第二個伺服器上，將客戶端部分放在第三個伺服器上。 為此，我們在 Kubernetes 部署中使用 NodeSelector。

我們將按以下比例描述基準測試結果：

選擇 CNI 作為基準

這只是本部分清單中 CNI 的基準 關於使用 kubeadm 建立一個主集群 請參閱 Kubernetes 官方文件。 在 9 個 CNI 中，我們只選擇 6 個：我們將排除那些難以安裝和/或在沒有根據文件配置的情況下無法工作的 CNI（Romana、Contiv-VPP 和 JuniperContrail/TungstenFabric）。

我們將比較以下 CNI：

• 印花布 v3.6
• Canal v3.6（本質上是用於網路的 Flannel + 作為防火牆的 Calico）
• 纖毛1.4.2
• 法蘭絨0.11.0
• Kube-路由器 0.2.5
• 編織網2.5.1

安裝

CNI 安裝越容易，我們的第一印象就越好。 基準測試中的所有 CNI 都非常容易安裝（只需一兩個命令）。

正如我們所說，伺服器和交換器配置為啟用巨型訊框（我們將 MTU 設定為 9000）。 如果 CNI 根據適配器的配置自動確定 MTU，我們會很高興。 然而，只有 Cilium 和 Flannel 做到了這一點。 其餘的 CNI 在 GitHub 上請求添加自動 MTU 發現，但我們將透過更改 Calico、Canal 和 Kube-router 的 ConfigMap 或傳遞 WeaveNet 的環境變數來手動配置它。

MTU 不正確會產生什麼問題？ 下圖顯示了預設 MTU 和啟用巨型幀的 WeaveNet 之間的差異：

MTU 如何影響吞吐量？

我們已經了解了 MTU 對性能的重要性，現在讓我們看看我們的 CNI 如何自動確定它：

CNI自動偵測MTU

此圖顯示您需要為 Calico、Canal、Kube-router 和 WeaveNet 配置 MTU 以獲得最佳效能。 Cilium 和 Flannel 無需任何設定即可自行正確確定 MTU。

安全

我們將從兩個方面來比較 CNI 的安全性：加密傳輸資料的能力和 Kubernetes 網路策略的實作（基於真實測試，而非文件）。

只有兩個 CNI 加密資料：Cilium 和 WeaveNet。 加密 編織網 透過將加密密碼設定為 CNI 環境變數來啟用。 在 文件 WeaveNet 描述得很複雜，但一切都做得很簡單。 加密 檸檬 透過指令、建立 Kubernetes 金鑰以及修改 daemonSet 來設定（比 WeaveNet 稍微複雜一點，但 Cilium 已經一步步進行了） 路線).

在網路政策的實施方面，他們取得了成功 Calico、Canal、Cilium 和 WeaveNet，您可以在其中配置入口和出口規則。 為了 Kube路由器 僅針對 Ingress 有規則，並且 絨布 根本沒有網路策略。

以下是整體結果：

安全績效基準結果

Производительность

此基準測試顯示每個測試至少執行三次的平均吞吐量。 我們測試了TCP 和UDP（使用iperf3）、HTTP（使用Nginx 和curl）或FTP（使用vsftpd 和curl）等實際應用程式的效能，最後使用基於SCP 的加密（使用客戶端和伺服器OpenSSH）的應用程式性能。

對於所有測試，我們執行了裸機基準測試（綠線），以將 CNI 效能與本機網路效能進行比較。 這裡我們使用相同的比例，但顏色不同：

• 黃色=非常好
• 橙色=好
• 藍色=馬馬虎虎
• 紅色=不好

我們不會採用錯誤配置的 CNI，並且只會顯示具有正確 MTU 的 CNI 的結果。 （注意：如果啟用加密，Cilium 不會正確計算 MTU，因此您必須在版本 8900 中手動將 MTU 減少到 1.4。下一版本 1.5 會自動執行此操作。）

結果如下：

TCP效能

所有 CNI 在 TCP 基準測試中都表現良好。 具有加密功能的 CNI 遠遠落後，因為加密成本高。

UDP性能

在這方面，所有 CNI 也都表現良好。 加密後的 CNI 顯示了幾乎相同的結果。 Cilium 稍微落後於競爭對手，但只有裸機的 2,3%，所以這個結果還不錯。 不要忘記，只有 Cilium 和 Flannel 自己正確地確定了 MTU，而這些是它們的結果，沒有任何額外的配置。

真正的應用又如何呢？ 正如您所看到的，HTTP 的整體效能略低於 TCP。 即使您將 HTTP 與 TCP 結合使用，我們也會在 TCP 基準測試中配置 iperf3，以避免啟動緩慢而影響 HTTP 基準測試。 這裡每個人都做得很好。 Kube-router 優勢明顯，但 WeaveNet 表現不佳：比裸機差約 20%。 帶有加密功能的 Cilium 和 WeaveNet 看起來真的很悲傷。

對於另一種基於 TCP 的協定 FTP，結果各不相同。 Flannel 和 Kube-router 可以完成這項工作，但 Calico、Canal 和 Cilium 稍微落後，比裸機慢約 10%。 WeaveNet 落後多達 17%，但加密的 WeaveNet 領先加密的 Cilium 40%。

透過 SCP，我們可以立即看到 SSH 加密的成本是多少。 幾乎所有 CNI 都表現良好，但 WeaveNet 再次落後。 由於雙重加密（SSH + CNI），具有加密功能的 Cilium 和 WeaveNet 預計是最糟糕的。

以下是包含結果的總結表：

資源消耗

現在我們來比較一下 CNI 在重負載下（TCP 傳輸期間，10 Gbps）如何消耗資源。 在性能測試中，我們將 CNI 與裸機進行比較（綠線）。 對於資源消耗，我們展示沒有 CNI 的純 Kubernetes（紫色線），看看 CNI 消耗了多少額外資源。

讓我們從記憶開始。 這是傳輸期間節點 RAM（不包括緩衝區和高速緩存）的平均值（以 MB 為單位）。

內存消耗

Flannel 和 Kube-router 顯示出出色的結果 - 僅 50 MB。 Calico 和 Canal 各有 70 個。WeaveNet 顯然比其他網路消耗更多 - 130 MB，而 Cilium 使用多達 400 MB。
現在讓我們檢查一下CPU 時間消耗。 值得注意的：此圖顯示的不是百分比，而是 ppm，即「裸鐵」的 38 ppm 為 3,8%。 結果如下：

CPU消耗

Calico、Canal、Flannel 和 Kube-router 的 CPU 效率非常高 - 僅比沒有 CNI 的 Kubernetes 高 2%。 WeaveNet 遠遠落後，多出了 5%，其次是 Cilium，為 7%。

資源消耗總結如下：

結果

包含所有結果的表：

一般基準測試結果

結論

在最後一部分我將表達我對結果的主觀看法。 請記住，此基準測試僅測試非常小的叢集（3 個節點）上單一連接的吞吐量。 它不適用於大型叢集（<50 個節點）或並行連接。

我建議根據場景使用以下 CNI：

• 你的集群中有 資源較少的節點 （幾GB RAM，幾個核心）並且您不需要安全功能 - 選擇 絨布。 這是最具成本效益的 CNI 之一。 並且相容於多種架構（amd64、arm、arm64等）。 此外，這是兩個可以自動確定 MTU 的 CNI（另一個是 Cilium）之一，因此您無需配置任何內容。 Kube-router 也適用，但它不是標準的，您需要手動配置 MTU。
• 如有必要 加密網路 為了安全，請採取 編織網。 如果您使用巨型幀，請不要忘記指定 MTU 大小，並透過環境變數指定密碼來啟用加密。 但最好忘記效能——這就是加密的成本。
• 為 正常使用 科韋圖什 印花布。 此CNI廣泛應用於各種Kubernetes部署工具（Kops、Kubespray、Rancher等）。 與 WeaveNet 一樣，如果使用巨型幀，請務必在 ConfigMap 中設定 MTU。 它是一個在資源消耗、效能和安全性方面高效的多功能工具。

最後，建議大家關注事態發展 檸檬。 這個 CNI 擁有一個非常活躍的團隊，在他們的產品上做了大量工作（功能、資源節省、效能、安全性、叢集...），並且他們有非常有趣的計劃。

CNI選型視覺化圖

來源： www.habr.com