本文是对我之前的基准测试（2018年和2019年）的更新，该基准测试基于Kubernetes 1.19和Ubuntu 18.04，并于2020年8月更新了CNI版本。

1) 基准测试申明

1.1) 自2019年4月以来的变动 ?

  • 测试您本人的集群：当初，您能够应用咱们的“ Kubernetes网络基准”工具公布的版本在您本人的集群上运行基准测试: knb (https://github.com/InfraBuilder/k8s-bench-suite)。
  • 欢送来到CNI战斗中的新挑战者：VMware Tanzu的“Antrea” 和 alauda.io的“Kube-OVN”
  • 新计划：此基准测试涵盖“ Pod-to-Pod”网络性能，但也波及到新的“ Pod-to-Service”计划，该计划波及理论测试案例。实际上，您的API容器将通过服务而不是容器IP耗费服务中的数据库（当然，咱们会在两种状况下都测试TCP和UDP）。
  • 资源耗费：当初，每个测试都有本人的资源比拟。
  • 删除了某些测试：咱们不再运行HTTP，FTP和SCP测试。咱们与社区和CNI维护者的行之有效的单干突显了iperf TCP后果与curl后果之间的差距，这是因为CNI启动的提早（在Pod启动的最后几秒钟，在理论应用案例中并不令人欣慰）。
  • 开源：所有基准测试源（脚本，CNI yml和原始后果）都能够在github上找到：https://github.com/InfraBuilder/benchmark-k8s-cni-2020-08。

1.2) 基准测试协定

整个协定在https://github.com/InfraBuilder/benchmark-k8s-cni-2020-08/blob/master/PROTOCOL.md中有具体阐明

请留神，以后文章仅关注具备默认内核的Ubuntu 18.04。

1.3) 抉择CNI作为基准

该基准旨在比拟能够与单个yaml文件设置的CNI（因而不包含所有基于脚本的装置，如基于VPP的CNI等）。

咱们将比拟的CNI如下：

  • Antrea v.0.9.1
  • Calico v3.16
  • Canal v3.16 (Flannel network + Calico Network Policies)
  • Cilium 1.8.2
  • Flannel 0.12.0
  • Kube-router latest (2020–08–25)
  • WeaveNet 2.7.0

2) CNI MTU tuning

首先，咱们将查看MTU检测对TCP性能的影响：

UDP的影响更加显著：

思考到此处显示的对性能的微小影响，咱们心愿向所有CNI维护者传播有意义的信息：请在CNI中施行MTU自动检测。

然而，如果您的确必须抉择未实现主动MTU的CNI，则须要本人对其进行调整以放弃性能。请留神，这实用于Calico, Canal 和 Weavenet。

3) CNI 基准测试 : 原始数据

在本节中，咱们将比拟CNI与正确的MTU（自动检测或手动调整）。这里的次要指标是在图表中显示原始数据。

  • Gray : Reference (aka Bare metal)
  • Green : bandwidth > 9 500 Mbit/s
  • Yellow : bandwidth > 9 000 Mbit/s
  • Orange : bandwidth > 8 000 Mbit/s
  • Red : bandwidth < 8 000 Mbit/s
  • Blue : neutral (not-bandwidth related)

3.1) Idle

第一件事是在整个集群处于闲暇时建设CNI消耗量？

3.2) Pod-to-Pod

在这种状况下，客户端Pod通过其IP地址间接连贯到服务器Pod。

3.2.1) TCP

“ Pod到Pod” TCP的后果和相干资源耗费如下：

3.2.2) UDP

“ Pod-to-Pod” UDP和相干资源耗费的后果如下：

3.3) Pod-to-Service

在本节中，客户端Pod通过ClusterIP服务连贯到服务器Pod。这与理论用例更相干。

3.3.1) TCP

“ Pod到服务” TCP的后果和相干资源耗费如下：

3.3.2) UDP

“ Pod到服务” UDP的后果和相干资源耗费如下：

3.4) 网络策略

在此基准测试中列出的所有CNI中，惟一不能齐全反对网络策略的是Flannel。其余所有接口都正确地施行了网络策略，包含入口和进口。

4) CNI Encryption

在咱们测试的所有CNI中，以下可能加密Pod间的通信：

  • Antrea with IPsec
  • Calico with wireguard
  • Cilium with IPsec
  • WeaveNet with IPsec

4.1) Bandwidth

因为这场战斗中的CNI较少，因而让咱们在一张图中概括所有场景：

4.2) 资源耗费

在本节中，咱们将查看Pod到Pod通信应用的资源，包含TCP和UDP。在此处显示Pod至服务图没有意义，因为它没有提供更多信息。

5) 总结

让咱们尝试回顾所有这些图表。咱们在这里通过用“very fast”，”low”等修饰符代替理论值来引入一些主观性。

6) 个人观点

最初一部分是主观的，传播了我对后果的解释。

我很快乐看到CNI的新成员退出。Antrea提供了许多性能，甚至在晚期版本中也施展了杰出的作用：主动mtu，加密选项和间接装置。

思考到性能，除Kube-OVN和Kube-Router外，所有CNI都体现良好。对于Kube-Router，它无奈检测到MTU，并且我在文档的任何中央都找不到调整它的办法（此处存在无关MTU配置的未解决问题）。

在资源耗费方面，Cilium仍比竞争对手应用更多的RAM，但该公司公开地针对大型集群，而这3个节点的基准状况并非如此。 Kube-OVN也是RAM和CPU密集型设施，它依然是一个年老的CNI，它依赖于Open vSwitch（Antrea也是如此，但Antrea更轻便并且性能更好）。

网络策略由除Flannel之外的所有通过测试的CNI施行。Flannel很可能永远不会（永远）实现它，因为他们的目标很明确：越轻越好。

此外，加密性能是这里真正的令人诧异的成果。 Calico是最古老的CNI之一，然而直到几周前它们才提供加密。他们更喜爱应用wireguard，而不是IPsec，至多能够说，它在该畛域中表现出色。当然，因为加密负载，它耗费了大量的CPU，然而它们实现的带宽是齐全值得的（请记住，Calico加密的性能大概是Cilium的6倍，后者排名第二）。此外，在集群上部署Calico之后，您还能够随时激活Wireguard加密，也能够在短期内或永恒禁用它。这是十分用户敌对的。然而！咱们提醒您，Calico目前无奈自动检测MTU（该性能打算在不久后公布），因而，如果您的网络反对巨型帧（MTU 9000），请不要遗记调整MTU。

此外，请留神Cilium可能加密整个节点到节点的流量（不仅是pod流量），这对于面向公众的集群节点来说可能是一个十分吸引人的性能。

总结一下，这是我对以下用例的倡议：

  • 我须要一个CNI来包容额定的小型节点集群，或者我不在乎安全性
    而后应用Flannel，这简直是最轻的稳固CNI。
  • 我的规范集群须要一个CNI
    好的，Calico是您的抉择，如果须要，请不要遗记调整MTU。您能够应用网络策略，轻松启用/禁用加密等。
  • 我的（十分）大型集群须要一个CNI
    好吧，该基准测试无奈反映大型集群的行为。我很乐意为此工作，然而咱们没有数百台具备10Gbit / s连接性的服务器。因而，最好的抉择是至多应用Calico和Cilium在您的节点上运行自定义的基准测试。

PS: 本文属于翻译，原文