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实现的。

以下是我们将用于描述基准测试结果和解释的比例:

 

Kubernetes(k8s)网络插件(CNI)的基准测试对比-LMLPHP

缩放结果的解释

为基准选择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帧之间的区别:

 

Kubernetes(k8s)网络插件(CNI)的基准测试对比-LMLPHP

MTU设置对带宽性能的影响

以下是设置结果的摘要:

 

Kubernetes(k8s)网络插件(CNI)的基准测试对比-LMLPHP

设置基准测试结果摘要

安全

在比较这些CNI的安全性时,我们谈论两件事:它们加密通信的能力,以及它们对Kubernetes网络策略的实现(根据实际测试,而不是来自他们的文档)。

可以加密通信的面板唯一的CNI是WeaveNet。这是通过将加密密码设置为CNI的ENV变量来完成的,这很容易做到。

在网络政策实施方面,通过实施Ingress和Egress规则,Calico,Canal和Cilium是最好的面板。Kube-router和WeaveNet实际上只实现了Ingress规则。Flannel和Romana不实施网络政策。(Nota bene:Romana的文档是指网络策略的实现,但这是通过自定义Romana资源而不是Kubernetes网络策略实现的)

以下是结果摘要:

 

Kubernetes(k8s)网络插件(CNI)的基准测试对比-LMLPHP

安全基准测试结果摘要

性能

该基准测试显示每次测试的三次运行(至少)的平均带宽。我们正在测试TCP和UDP性能(使用iperf3),真实应用程序,如HTTP(使用nginx和curl),或FTP(使用vsftpd和curl),最后是使用SCP协议进行应用程序加密的行为(使用OpenSSH服务器和客户端)。

对于所有测试,我们还在裸机节点(绿色条)上运行基准测试,以比较CNI与本机网络性能的有效性。为了与我们的基准比例保持一致,我们在图表上使用以下颜色:

  • 黄色=非常好
  • 橙色=好
  • 蓝色=一般
  • 红色=差

结果如下:

 

Kubernetes(k8s)网络插件(CNI)的基准测试对比-LMLPHP

TCP性能

我们可以在TCP结果上看到所有CNI都非常好,除了WeaveNet加密,因为加密过程会大大降低性能。

 

Kubernetes(k8s)网络插件(CNI)的基准测试对比-LMLPHP

UDP性能

在UDP基准测试中,WeaveNet加密的结果比TCP更差(大约1/3因子)。没有加密的WeaveNet只是其他一些但仍然合理(97%的裸机性能)。我们可以注意到Kube-router和Romana比裸机更快(小于1%):测试已重复运行多次,结果稳定。

 

Kubernetes(k8s)网络插件(CNI)的基准测试对比-LMLPHP

HTTP性能

即使HTTP是基于TCP的协议,现实应用似乎也会对性能产生影响。该测试基本上是一个10GB随机字节的文件(以避免可能的压缩副作用),由nginx提供,并从curl客户端下载。WeaveNet Encrypted现在以TCP性能的17%运行,而Cilium似乎也在处理这个测试时出现了一些问题。没有加密的WeaveNet,法兰绒和运河也落后于其他CN

Kubernetes(k8s)网络插件(CNI)的基准测试对比-LMLPHP

FTP性能

使用FTP测试,结果与HTTP非常相似,只是WeaveNet未加密的行为与Cilium类似,两者都落后于其他CNI。WeaveNet加密像往常一样,性能非常低。此测试与HTTP的情况相同,只是我们在匿名模式下用VSFTPD替换nginx。

Kubernetes(k8s)网络插件(CNI)的基准测试对比-LMLPHP

SCP表现

使用SCP,我们使用OpenSSH服务器和客户端在scp上传输10GB随机文件。我们可以清楚地看到,即使裸机性能也比以前低得多。所有CNI都相当,除了WeaveNet Encrypted,它遭受双重加密(SCP +网络加密)。

以下是CNIs表现的总结:

 

Kubernetes(k8s)网络插件(CNI)的基准测试对比-LMLPHP

表现基准测试结果摘要

资源消耗

现在让我们比较这些CNI在负载很重的情况下如何处理资源消耗(在TCP 10Gbit传输期间)。在性能测试中,我们将CNI与裸金属(绿色条)进行比较。对于资源消耗测试,我们还显示在没有任何CNI设置的情况下闲置(紫色条)的新鲜Kubernetes的消耗。然后我们可以计算出CNI真正消耗了多少。

让我们从内存方面开始吧。以下是传输期间以MB为单位的平均节点RAM使用率(无缓冲区/缓存)。

 

Kubernetes(k8s)网络插件(CNI)的基准测试对比-LMLPHP

平均节点RAM使用率(无缓冲区/缓存)

我们可以清楚地看到Flannel是最瘦的,只比没有CNI的Kubernetes多20MB。Calico,Canal,Kube-router和Romana都接近法兰绒,而WeaveNet稍稍落后于WeaveNet,这表明加密对内存消耗没有影响。纤毛比其他纤维消耗更多的记忆。

现在,让我们看看CPU消耗。警告:图形单位不是百分比,而是permil。因此,裸金属的1 permil实际上是0.1%。结果如下:

 

Kubernetes(k8s)网络插件(CNI)的基准测试对比-LMLPHP

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消耗更多。

以下是资源消耗部分的摘要:

 

Kubernetes(k8s)网络插件(CNI)的基准测试对比-LMLPHP

资源消耗总结

摘要

以下是所有汇总结果的概述:

 

Kubernetes(k8s)网络插件(CNI)的基准测试对比-LMLPHP

所有结果的快速摘要

结论

最后一部分是主观的,并传达了我自己对结果的解释。如果你在相应的场景中,我建议使用以下CNI:

  • 您的群集中有低资源节点(只有几GB的RAM,很少的内核),并且您不需要安全功能,请使用Flannel。这是我们测试过的最精简的CNI。而且,它与许多架构兼容(amd64,arm等)。
  • 出于安全原因,您需要加密网络,请使用WeaveNet。如果您使用巨型帧并通过在环境变量中提供密码来激活加密,请不要忘记设置MTU大小。但话说回过来,忘掉性能,这就是加密的代价。
  • 对于其他常见用法,我会推荐Calico。就像WeaveNet一样,如果您使用的是巨型帧,请不要忘记在ConfigMap中设置MTU。事实证明,它在资源消耗,性能和安全性方面具有多用途和高效性。Calico已经在非常大的集群上工作,并且具有非常有趣的BGP功能。
 

Kubernetes(k8s)网络插件(CNI)的基准测试对比-LMLPHP

05-11 20:17