Skip to main content

前言

本文參考自 Benchmark results of Kubernetes network plugins (CNI) over 10Gbit/s network (Updated: August 2020)，主要用來記錄閱讀的心得分享，詳細全文請點選上述連結觀看。

環境​

本篇文章的環境基於下列版本

  1. Kubernetes: 1.19
  2. Ubuntu: 18.04
  3. 受測 CNI:
    1. Antrea v.0.9.1
    2. Calico v3.16
    3. Canal v3.16 (Flannel network + Calico Network Policies)
    4. Cilium 1.8.2
    5. Flannel 0.12.0
    6. Kube-router latest (2020–08–25)
    7. WeaveNet 2.7.0

內容是 2020 8月份時進行的實測結果

該文用到的所有測試工具全部都開源並放到 Github 上，對其專案有興趣的可以到這邊觀看內容 benchmark-k8s-cni-2020-08 或是閱讀本文的第一大章節，有介紹一些工具的使用。

MTU 的影響

文章中針對三款 CNI (Calico, Canal, WeaveNet) 測試看看 偵測MTU的功能 基於 TCP/UDP 下的效能如何

TCP​

CNI\MTUAuto MTUCustom MTU
Calico88769834
Canal85309817
Weave Net48809759

以上數字都是 Mbit/s

UDP​

CNI\MTUAuto MTUCustom MTU
1Calico19019757
Canal18209742
Weave Net18099593

以上數字都是 Mbit/s

結論​

上述的結論可以看到 Auto MTU 的效能都非常差，原因並不是 Auto MTU 沒有效，而是因為這些 CNI 目前根本沒有支持 Auto MTU 的做法，而 Calico 直到 3.7 版本才正式支持 Auto MTU 這個功能，而且根據作者的測試其功能良好。

作者認為對於這種需要設定 Jumbo frames 的環境下，如果沒有 Auto MTU 的話，管理員則需要手動去設定這些 MTU，所以非常希望每個 CNI 能夠去實作 Auto MTU 的功能來自動偵測並且設定，減少管理員需要人工介入的需求。

至於其他的 CNI 為什麼沒有測試，因為他們都有實作 Auto-MTU 的功能

  1. Antrea
  2. Cilium
  3. Flannel
  4. Kube-OVN

其中 Kube-router 這邊作者標示為 None, 估計可能是根本不能設定 MTU

使用 Raw Data 來進行 CNI 的評測

這章節主要會用來比較這些再正確 MTU 設定下不同 CNI 之間的效能比較

資源效能評比​

一開始作者先比較基於閒置狀況下，不同 CNI 所消耗的資源狀況，包含了 CPU 以及 Memory。

原文中是用 CPU(%) 以及 Memory (MB) 來畫圖，我則是將這些數字用幾個等級來區分，數字愈低代表使用量愈低

CNI\資源類型CPUMemory
Antrea34
Calico34
Canal34
Cilium55
Flannel23
Kube-OVN84
Kube-router33
Weave Net23
裸機12

這邊可以觀察到

  1. Weave Net/Flannel 的資源使用量最低

  2. Cilium 資源使用量偏高

  3. Kube-OVN 資源使用量最高

  4. 剩下的資源使用量都差不多，我認為可以算是同一個等級

Kube-OVN > Cilium > 剩下全部 > WeaveNet/Flannel

Pod to Pod​

接下來看一下 Pod to Pod 的存取，這邊的方式是直接用 Pod 的 IP 來存去，並不是任何用 Service 這種方式來存取。

TCP​

CNI\PerformanceMbit/s
Antrea9826
Calico9834
Canal9817
Cilium9426
Flannel9690
Kube-OVN9029
Kube-router8051
Weave Net9759
裸機9906

從上面的數據可以觀察到

  1. Kube-router 的數據最差
  2. Kube-OVN 也沒有很好，大概就 9Gb/s 左右
  3. Cilium 大概介於 9.5Gb/s
  4. 剩下的都 CNI 效能跟裸機都不會差太多

接下來觀察一下這個實驗中，不同 CNI 的資源消耗量，原文中是用 CPU(%) 以及 Memory (MB) 來畫圖，我則是將這些數字用幾個等級來區分，數字愈低代表使用量愈低

CNI\資源類型CPUMemory
Antrea23
Calico23
Canal23
Cilium34
Flannel23
Kube-OVN44
Kube-router23
Weave Net33
裸機12

從上面的結論觀察，我認為跟 閒置 的情況差不多，唯一的差異就是 Weavenet 從最少使用量的 CNI 變成第三高

Kube-OVN > Cilium > WeaveNet > 剩下全部

UDP​

CNI\PerformanceMbit/s
Antrea9796
Calico9757
Canal9742
Cilium9726
Flannel9846
Kube-OVN5833
Kube-router2810
Weave Net9539
裸機9885

從上面的數據可以觀察到

  1. Kube-router 的數據最差，連 3Gb/s 都不到，非常慘，不到 30% 的效能
  2. Kube-OVN 也很不好，大概只有 6Gb/s
  3. 剩下的都 CNI 效能跟裸機都不會差太多

接下來觀察一下這個實驗中，不同 CNI 的資源消耗量，原文中是用 CPU(%) 以及 Memory (MB) 來畫圖，我則是將這些數字用幾個等級來區分，數字愈低代表使用量愈低

CNI\資源類型CPUMemory
Antrea44
Calico34
Canal34
Cilium45
Flannel34
Kube-OVN55
Kube-router44
Weave Net44
裸機22

從上面的結論觀察，跟 閒置 比較起來比較有一些變化

  1. Kube-OVN 永遠都是使用資源第一名
  2. Cilium 還是第二名
  3. 第三名則是 WeaveNet/Antrea/Kube-Router
  4. 剩下的等級差不多

Kube-OVN > Cilium > WeaveNet/Antrea/Kube-Router > Calico/Canal/Flannel > 裸機

Pod to Service​

這個情況下則是探討透過 Service 來存取目標 Pod，也是基於 TCP/UDP 來測試，其中 Service 則是基於 ClusterIP 的設定才測試。

TCP​

CNI\PerformanceMbit/s
Antrea9789
Calico9841
Canal9757
Cilium9630
Flannel9826
Kube-OVN9409
Kube-router8380
Weave Net9749

從上面的數據可以觀察到

  1. Kube-router 的數據最差, 大概只剩下 85% 效能
  2. Kube-OVN 還行，大概 95%
  3. 剩下的都 CNI 效能都差不多， 97% +-1%。

接下來觀察一下這個實驗中，不同 CNI 的資源消耗量，原文中是用 CPU(%) 以及 Memory (MB) 來畫圖，我則是將這些數字用幾個等級來區分，數字愈低代表使用量愈低

CNI\資源類型CPUMemory
Antrea34
Calico24
Canal24
Cilium35
Flannel24
Kube-OVN45
Kube-router24
Weave Net34

從上面的結論觀察，跟 閒置 比較起來比較有一些變化

  1. Kube-OVN 永遠都是使用資源第一名
  2. Cilium 還是第二名
  3. 第三名則是 WeaveNet/Antrea
  4. 剩下的等級差不多

Kube-OVN > Cilium > WeaveNet/Antrea > Kube-Router/Calico/Canal/Flannel > 裸機

相對於 Pod to Pod 的情況來看， Pod to Service 中 Antrea 的效能消耗更高，從第四名那群躍升到第三名。

UDP​

CNI\PerformanceMbit/s
Antrea8618
Calico9420
Canal9800
Cilium9712
Flannel9825
Kube-OVN5380
Kube-router2781
Weave Net9154

從上面的數據可以觀察到

  1. Kube-router 的數據最差，連 3Gb/s 都不到，非常慘，不到 30% 的效能
  2. Kube-OVN 也很不好，大概只有 5Gb/s
  3. Antrea 的效能也不好了，大概只有 8.6 Gb/s
  4. Calico 以及 WeaveNet 的效能也都降到 95% 以下，不到 9.5Gb/s
  5. 剩下的都 CNI 效能都差不多 (Canal/Cilium/Flannel)

接下來觀察一下這個實驗中，不同 CNI 的資源消耗量，原文中是用 CPU(%) 以及 Memory (MB) 來畫圖，我則是將這些數字用幾個等級來區分，數字愈低代表使用量愈低

CNI\資源類型CPUMemory
Antrea44
Calico34
Canal34
Cilium45
Flannel34
Kube-OVN45
Kube-router34
Weave Net44

從上面的結論觀察，跟 閒置 比較起來比較有一些變化

  1. Kube-OVN 跟 Cilium 兩個各有千秋，一個 CPU 用比較多，一個則是記憶體比較多
  2. Antrea/WeaveNet/Kube-router 三者消耗的層級差不多
  3. Calico/Canal/Flannel 三者差不多

Kube-OVN/Cilium > WeaveNet/Antrea/Kube-Router > Calico/Canal/Flannel

Network Policies​

這邊沒有任何的數據測試，除了 Flannel 外，剩下的 CNI 都有實現 Ingress/Egress(往內/往外) 的 Network Policies，很棒!

CNI 加密

測試的 CNI 解決方案中，只有四套有支援資料加密的部分，分別是

  1. Antrea (IPSec)
  2. Calico (wireguard)
  3. Cilium (IPSec)
  4. WeaveNet (IPSec)

效能部分​

因為這邊效能比較少，所以我們將 TCP/UDP 放在一起評比

Pod to Pod TCP/UDP​

CNI\PerformanceTCP (Mbit/s)UDP (Mbit/s)
Antrea1392742
Calico97864877
Cilium1657869
WeaveNet1384432

這邊可以觀察到

  1. TCP 的效能遠勝於 UDP
  2. 使用 wireguard 的效能完全輾壓 IPSec 技術的其他 CNI
  3. 三個都使用 IPSec 的 CNI，其中 WeaveNet 效能是其中最差的，而 Cilium 則是效能最好的

資源效能評比 TCP/UDP​

TCP​

接下來觀察一下這個實驗中，不同 CNI 的資源消耗量，原文中是用 CPU(%) 以及 Memory (MB) 來畫圖，我則是將這些數字用幾個等級來區分，數字愈低代表使用量愈低

CNI\資源類型CPUMemory
Antrea24
Calico44
Cilium25
WeaveNet24

從上面的結論觀察，跟 閒置 比較起來比較有一些變化

  1. Calico 使用的資源最多
  2. 剩下三者差不多

UDP​

接下來觀察一下這個實驗中，不同 CNI 的資源消耗量，原文中是用 CPU(%) 以及 Memory (MB) 來畫圖，我則是將這些數字用幾個等級來區分，數字愈低代表使用量愈低

CNI\資源類型CPUMemory
Antrea24
Calico44
Cilium25
WeaveNet24

從上面的結論觀察，跟 閒置 比較起來比較有一些變化

  1. Calico 使用的資源最多
  2. 剩下三者差不多

Pod to Service TCP/UDP​

CNI\PerformanceTCP (Mbit/s)UDP (Mbit/s)
Antrea1390735
Calico98084872
Cilium1661866
WeaveNet1381451

這邊可以觀察到其結果與 Pod-to-Pod 是差不多的，因此結論完全一致

  1. TCP 的效能遠勝於 UDP
  2. 使用 wireguard 的效能完全輾壓 IPSec 技術的其他 CNI
  3. 三個都使用 IPSec 的 CNI，其中 WeaveNet 效能是其中最差的，而 Cilium 則是效能最好的

總結

根據上述的全部來源，我們可以繪製數張總結表格，效能的部分採用相對比較，對原始數字有興趣的可以參考其公開的 Github 專案。

評比標準: 好>普通>不好

MTU/加密效果​

---MTU設定Network Policy(往內)Network Policy(往外)加密設定加密後傳輸效能加密資源消耗量
Antrea自動偵測支援支援支援(部署時設定)普通普通
Calico手動設定支援支援動態設定好不好
Canal手動設定支援支援不支援n/an/a
Cilium自動偵測支援支援支援(部署時設定)普通普通
Flannel自動偵測不支援不支援不支援n/an/a
Kube-OVN自動偵測支援支援不支援n/an/a
Kube-router無支援支援不支援n/an/a
Weave Net手動設定支援支援支援(部署時設定)普通普通

流量評比​

這邊使用一些縮寫

P2P -> Pod to Pod

P2S -> Pod to Service

---P2P/TCPP2P/UDPP2S/TCPP2S/UDP
Antrea很好很好很好普通
Calico很好很好很好好
Canal很好很好很好很好
Cilium好很好很好很好
Flannel很好很好很好很好
Kube-OVN好很差好很差
Kube-router很差很差很差超級差
Weave Net很好很好很好好

資源消耗評比​

這邊使用一些縮寫

P2P -> Pod to Pod

P2S -> Pod to Service

同時評比的概念是使用的資源多寡，採用相對等級

超高>有點高>普通>少

---閒置P2P/TCPP2P/UDPP2S/TCPP2S/UDP
Antrea普通普通普通普通普通
Calico普通普通少少少
Canal普通普通少少少
Cilium有點高超高有點高有點高超高
Flannel少普通少少少
Kube-OVN超高超高超高有點高超高
Kube-router普通普通普通少普通
Weave Net少有點高普通普通普通

透謝圖表可以觀察到

  1. Kube-OVN 不但資源吃很多，效能還很不好
  2. Canal/Calico/Flannel 三者的運算資源使用量都不多，且效能都很好
  3. Kube-Router 的效能都很差，資源使用方便也不是特別出色
  4. WeaveNet 與 Cilium 效能都不差，但是 Cilium 吃的效能很高，可說跟 Kube-OVN 同等級，而 WeaveNet 用到的資源少

個人心得

  1. 這次的實驗評比我認為其實能看到的東西有限，主要是不同的 CNI 所搭配的解決方案不同，目標要配合的情境也不同，雖然從圖表中可以看到 Kube-OVN 的綜合評比最差，但是其要用的場景本身就不太一樣，單純用最原始的流量互打來判別優劣其實不太對
  2. 如果今天要選擇網路 CNI 的時候，可以看到效能跟資源方面， Flannel/Calico/Canal 幾乎等級都差不多，而且 Calico 還支援加密與 Network Policy 等功能。
  3. 此外，目前 Flannel 也從 Kubeadm 的官方教學頁面中移除，因為太多問題且維護者沒有要修復。所以我認為如果沒有特別使用情境需求的話，可以考慮使用 Calico.
  4. Cilium 對於安全性以及 load-balancing 方面也有別的功能，就如同(1)點所提到，不同的場景有不同的需求，有些功能是獨占的。

參考來源