Kubernetes(k8s)網絡插件（CNI）的基准測試對比

 

Kubernetes是一個偉大的容器"樂隊"。但它不管理Pod-to-Pod通信的網絡。這是容器網絡接口（CNI）插件的使命，它是實現容器集群工具（Kubernetes，Mesos，OpenShift等）的網絡抽象的標准化方法。

但重點是：這些CNI之間有什么區別？哪一個性能最好？哪一個最精瘦？

本文展示了我在10Gbit / s網絡上進行的基准測試的結果。這些結果也是在2018年11月15日在馬賽（法國）的Devops D-DAY 2018年的一次會議上提出的。

基准背景

基准測試是在通過Supermicro 10Gbit交換機連接的三台Supermicro裸機服務器上進行的。服務器通過DAC SFP +無源電纜直接連接到交換機，並在激活巨型幀（MTU 9000）的同一VLAN中設置。

Kubernetes 1.12.2在Ubuntu 18.04 LTS上運行，運行Docker 17.12（此版本的默認docker版本）。

為了提高可重復性，我們選擇始終在第一個節點上設置主設備，在第二個服務器上設置基准測試的服務器部分，在第三個服務器上設置客戶端部分。這是通過Kubernetes部署中的NodeSelector實現的。

以下是我們將用於描述基准測試結果和解釋的比例：

 

縮放結果的解釋

為基准選擇CNI

此基准測試僅關注集成在 文檔“bootstrap a cluster with kubeadm” 部分中的CNI列表。在提到的8個CNI中，我們不會測試“JuniperContrail / TungstenFabric”CNI，因為它需要3.10內核（ubuntu 18.04運行的是4.15內核）。

以下是我們將要比較的CNI列表：

• 印花布v3.3
• 運河v3.3（實際上是Flannel用於網絡+ Calico用於防火牆）
• Cilium 1.3.0
• 法蘭絨0.10.0
• Kube-router 0.2.1
• Romana 2.0.2
• WeaveNet 2.4.1

安裝

CNI最容易設置，我們的第一印象就是最好的。即使所有CNI都被描述為非常容易設置，但遵循文檔還不足以安裝Cilium和Rom​​ana。Cilium需要一個ETCD數據存儲區才能實現功能，我們必須搜索其文檔的minikube部分才能找到一個單行部署方法。Romana缺乏維護，因此無法處理Kubernetes 1.11對“未准備”節點上應用的Toleration所引入的最新更改（在CNI設置之前）。因此，Romana不會在一段時間內部署並讓您的節點“未准備就緒”！這需要修復Romana安裝Yaml文件中存在的所有部署/守護進程的Tolerations。

如前所述，服務器和交換機都配置了Jumbo幀激活（通過將MTU設置為9000）。我們非常感謝CNI可以自動發現要使用的MTU，具體取決於適配器。事實上，Cilium，Flannel和Romana是唯一能夠正確自動檢測MTU的人。大多數其他CNI在github中引發了一些問題以啟用MTU自動檢測，但是現在，我們需要通過修改Calico，Canal和Kube路由器的ConfigMap或WeaveNet的ENV var來手動修復它。

也許您想知道錯誤的MTU會產生什么影響？這是一個圖表，顯示WeaveNet與默認MTU和WeaveNet與Jumbo幀之間的區別：

 

MTU設置對帶寬性能的影響

以下是設置結果的摘要：

 

設置基准測試結果摘要

安全

在比較這些CNI的安全性時，我們談論兩件事：它們加密通信的能力，以及它們對Kubernetes網絡策略的實現（根據實際測試，而不是來自他們的文檔）。

可以加密通信的面板唯一的CNI是WeaveNet。這是通過將加密密碼設置為CNI的ENV變量來完成的，這很容易做到。

在網絡政策實施方面，通過實施Ingress和Egress規則，Calico，Canal和Cilium是最好的面板。Kube-router和WeaveNet實際上只實現了Ingress規則。Flannel和Romana不實施網絡政策。（Nota bene：Romana的文檔是指網絡策略的實現，但這是通過自定義Romana資源而不是Kubernetes網絡策略實現的）

以下是結果摘要：

 

安全基准測試結果摘要

性能

該基准測試顯示每次測試的三次運行（至少）的平均帶寬。我們正在測試TCP和UDP性能（使用iperf3），真實應用程序，如HTTP（使用nginx和curl），或FTP（使用vsftpd和curl），最后是使用SCP協議進行應用程序加密的行為（使用OpenSSH服務器和客戶端）。

對於所有測試，我們還在裸機節點（綠色條）上運行基准測試，以比較CNI與本機網絡性能的有效性。為了與我們的基准比例保持一致，我們在圖表上使用以下顏色：

• 黃色=非常好
• 橙色=好
• 藍色=一般
• 紅色=差

結果如下：

 

TCP性能

我們可以在TCP結果上看到所有CNI都非常好，除了WeaveNet加密，因為加密過程會大大降低性能。

 

UDP性能

在UDP基准測試中，WeaveNet加密的結果比TCP更差（大約1/3因子）。沒有加密的WeaveNet只是其他一些但仍然合理（97％的裸機性能）。我們可以注意到Kube-router和Romana比裸機更快（小於1％）：測試已重復運行多次，結果穩定。

 

HTTP性能

即使HTTP是基於TCP的協議，現實應用似乎也會對性能產生影響。該測試基本上是一個10GB隨機字節的文件（以避免可能的壓縮副作用），由nginx提供，並從curl客戶端下載。WeaveNet Encrypted現在以TCP性能的17％運行，而Cilium似乎也在處理這個測試時出現了一些問題。沒有加密的WeaveNet，法蘭絨和運河也落后於其他CN

FTP性能

使用FTP測試，結果與HTTP非常相似，只是WeaveNet未加密的行為與Cilium類似，兩者都落后於其他CNI。WeaveNet加密像往常一樣，性能非常低。此測試與HTTP的情況相同，只是我們在匿名模式下用VSFTPD替換nginx。

SCP表現

使用SCP，我們使用OpenSSH服務器和客戶端在scp上傳輸10GB隨機文件。我們可以清楚地看到，即使裸機性能也比以前低得多。所有CNI都相當，除了WeaveNet Encrypted，它遭受雙重加密（SCP +網絡加密）。

以下是CNIs表現的總結：

 

表現基准測試結果摘要

資源消耗

現在讓我們比較這些CNI在負載很重的情況下如何處理資源消耗（在TCP 10Gbit傳輸期間）。在性能測試中，我們將CNI與裸金屬（綠色條）進行比較。對於資源消耗測試，我們還顯示在沒有任何CNI設置的情況下閑置（紫色條）的新鮮Kubernetes的消耗。然后我們可以計算出CNI真正消耗了多少。

讓我們從內存方面開始吧。以下是傳輸期間以MB為單位的平均節點RAM使用率（無緩沖區/緩存）。

 

平均節點RAM使用率（無緩沖區/緩存）

我們可以清楚地看到Flannel是最瘦的，只比沒有CNI的Kubernetes多20MB。Calico，Canal，Kube-router和Romana都接近法蘭絨，而WeaveNet稍稍落后於WeaveNet，這表明加密對內存消耗沒有影響。纖毛比其他纖維消耗更多的記憶。

現在，讓我們看看CPU消耗。警告：圖形單位不是百分比，而是permil。因此，裸金屬的1 permil實際上是0.1％。結果如下：

 

permil的平均CPU使用率（不是百分比）

Calico和Flannel比沒有CNI的kubernetes節點消耗不到1％的CPU，以實現10Gbit TCP傳輸，這是非常好的。Kube-router和Romana落后1.5％。WeaveNet uncrypted和Canal都很高，3％的開銷，但不如WeaveNet加密和Cilium，每個都超過4％。對於WeaveNet加密，這是非常合乎邏輯的，因為完整的10Gbit流是加密的，因此使用CPU來實現這一點。但是，在這種情況下，Cilium不會比加密的CNI消耗更多。

以下是資源消耗部分的摘要：

 

資源消耗總結

摘要

以下是所有匯總結果的概述：

 

所有結果的快速摘要

結論

最后一部分是主觀的，並傳達了我自己對結果的解釋。如果你在相應的場景中，我建議使用以下CNI：

• 您的群集中有低資源節點（只有幾GB的RAM，很少的內核），並且您不需要安全功能，請使用Flannel。這是我們測試過的最精簡的CNI。而且，它與許多架構兼容（amd64，arm等）。
• 出於安全原因，您需要加密網絡，請使用WeaveNet。如果您使用巨型幀並通過在環境變量中提供密碼來激活加密，請不要忘記設置MTU大小。但話說回過來，忘掉性能，這就是加密的代價。
• 對於其他常見用法，我會推薦Calico。就像WeaveNet一樣，如果您使用的是巨型幀，請不要忘記在ConfigMap中設置MTU。事實證明，它在資源消耗，性能和安全性方面具有多用途和高效性。Calico已經在非常大的集群上工作，並且具有非常有趣的BGP功能。