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

iyacontrol

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

阅读 3.1k

kubernetes solutions
专注k8s,serverless,service mesh,devops

专注kubernetes,devops,aiops,service mesh。

1.4k 声望
2.7k 粉丝
0 条评论

专注kubernetes,devops,aiops,service mesh。

1.4k 声望
2.7k 粉丝
文章目录
宣传栏