Kubernetes网络插件(CNI)的基准测试

本文是对我之前的基准测试（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: 本文属于翻译，原文