这是对我之前的基准的更新，该基准现在在Kubernetes 1.14上运行，当前的CNI版本为2019年4月。
首先，我要感谢Cilium团队：这些人帮助我检查并修复了指标监视脚本。
自2018年11月以来发生了什么变化
此后发生的变化（如果有兴趣）：
Flannel仍然是CNI最快，最简单的接口，但仍不支持网络策略和加密。
不再支持Romana，因此我们将其从基准中删除。
WeaveNet现在支持Ingress和Egress的网络策略！ 但是生产力下降了。
在Calico中，您仍然需要手动配置最大数据包大小（MTU），以获得更好的性能。 Calico提供了两个CNI安装选项，因此您可以在没有单独的ETCD存储库的情况下进行操作：
- 在Kubernetes API中将状态存储作为数据存储（集群大小<50个节点）；
- 状态存储在Kubernetes API中，作为带有Typha代理的数据存储，以减轻K8S API的负载（集群大小> 50个节点）。
Calico宣布在 Istio之上为应用程序级安全性提供应用程序级策略支持。
Cilium现在支持加密！ Cilium使用IPSec隧道提供加密，并提供了加密的WeaveNet网络的替代方案。 但是启用了加密功能的WeaveNet比Cilium快。
现在，由于内置的ETCD操作员，Cilium的部署更加容易。
Cilium团队试图减轻CNI的负担，从而减少了内存消耗和CPU成本，但竞争对手却更轻了。
基准环境
该基准测试在三台带有10 Gb Supermicro交换机的非虚拟化Supermicro服务器上运行。 服务器通过无源DAC SFP +电缆直接连接到交换机，并在具有巨型帧（MTU 9000）的同一VLAN中进行配置。
Kubernetes 1.14.0已安装在具有Docker 18.09.2（此发行版中的默认版本）的Ubuntu 18.04 LTS上。
为了提高可重复性，我们决定始终在第一个节点上配置主服务器，将基准测试的服务器部分放在第二台服务器上，将客户端部分放在第三台服务器上。 为此，我们在Kubernetes部署中使用NodeSelector。
基准结果将以这样的规模进行描述：
选择CNI作为基准
这是官方Kubernetes文档中有关使用kubeadm创建一个主群集的部分中列表的仅CNI基准。 在CNI 9中，我们仅采用6：我们排除了那些难以安装和/或在没有文档配置的情况下无法工作的产品（Romana，Contiv-VPP和JuniperContrail / TungstenFabric）。
我们将比较以下CNI：
- 印花布v3.6
- Canal v3.6（本质上是用于联网的绒布+ Calico作为防火墙）
- Cilium 1.4.2
- 绒布0.11.0
- Kube路由器0.2.5
- WeaveNet 2.5.1
安装方式
安装CNI越容易，我们的第一印象就会越好。 基准测试中的所有CNI都非常易于安装（只有一两个团队）。
如前所述，服务器和交换机配置了激活的巨型帧（我们安装了MTU 9000）。 如果CNI根据适配器设置自动确定MTU，我们将非常高兴。 但是，只有Cilium和Flannel处理此问题。 CNI的其余部分在GitHub上都有添加自动MTU检测的请求，但是我们将通过更改Calico，Canal和Kube-router的ConfigMap或通过传递WeaveNet的环境变量来手动配置它。
错误的MTU有什么问题？ 下图显示了启用默认MTU的WeaveNet和启用的巨型帧之间的区别：
MTU如何影响带宽
我们了解了MTU对性能的重要性，现在让我们看看CNI如何自动检测到它：
CNI自动检测MTU
该图显示您需要为Calico，Canal，Kube-router和WeaveNet配置MTU，以获得最佳性能。 Cilium和Flannel本身无需任何设置即可正确确定MTU。
安全性
我们将在两个方面比较CNI安全性：加密传输数据的能力和Kubernetes网络策略的实现（根据实际测试，而不是根据文档）。
只有两个CNI加密数据：Cilium和WeaveNet。 通过将加密密码设置为CNI环境变量来启用WeaveNet加密。 WeaveNet 文档描述了这很复杂，但是一切都简单地完成了。 通过命令，创建Kubernetes机密以及修改daemonSet 来配置Cilium加密（比WeaveNet复杂一点，但是Cilium具有分步说明 ）。
至于网络策略的实施， Calico，Canal，Cilium和WeaveNet在这里成功完成了，您可以在其中配置Ingress和Egress规则。 对于Kube-router，仅对Ingress有规则，而Flannel根本没有网络策略。
以下是一般结果：
安全功能基准测试结果
性能表现
此基准显示每个测试至少运行三个的平均吞吐量。 我们测试TCP和UDP（使用iperf3），真实应用程序（例如HTTP（使用Nginx和curl）或FTP（使用vsftpd和curl））的性能，最后测试使用基于SCP协议加密的应用程序（使用客户端和服务器）的性能。 OpenSSH）。
对于所有测试，我们都制定了裸机基准（绿线）以将CNI性能与本机网络性能进行比较。 在这里，我们使用相同的比例尺，但使用颜色：
我们不会采用配置不正确的CNI，而只会显示具有正确MTU的CNI的结果。 （注意：如果启用了加密，Cilium会错误地考虑MTU，因此您必须在版本1.4中手动将MTU降低到8900。在下一个版本1.5中，这是自动完成的。）
结果如下：
TCP性能
所有CNI在TCP基准测试中均表现良好。 加密的CNI远远落后，因为加密非常昂贵。
UDP性能
在这里，所有CNI都表现良好。 加密的CNI显示几乎相同的结果。 Cilium的竞争优势略逊于竞争对手，但仅占裸金属的2.3％，因此效果还不错。 不要忘记只有Cilium和Flannel自己可以正确确定MTU，而这些都是没有额外配置的结果。
真正的应用程序如何？ 如您所见，对于HTTP，总体性能略低于TCP。 即使您将HTTP与TCP一起使用，在TCP基准测试中，我们也配置了iperf3以避免启动缓慢，这会影响HTTP基准测试。 这里一切都做得很好。 Kube-router具有明显的优势，WeaveNet并没有从最好的方面证明自己：比裸机差20％。 具有加密功能的Cilium和WeaveNet看起来非常可悲。
使用FTP，这是另一个基于TCP的协议，结果是不同的。 绒布和Kube-router可以应付，而Calico，Canal和Cilium则稍稍落后，并且工作速度比裸机慢10％。 WeaveNet不能跟上多达17％的速度，但是带加密的WeaveNet比加密的Cilium高40％。
使用SCP，您可以立即看到SSH加密使我们付出了什么。 几乎所有的CNI都这样做，并且WeaveNet再次落后。 由于双重加密（SSH + CNI），具有加密功能的Cilium和WeaveNet预计将是最差的。
这是结果汇总表：
资源消耗
现在让我们比较一下CNI在高负载下（在TCP传输期间，10 Gb / s）消耗资源的方式。 在性能测试中，我们将CNI与裸机（绿线）进行了比较。 为了消耗资源，我们将显示不带CNI的纯Kubernetes（紫色线），并查看CNI消耗了多少额外资源。
让我们从内存开始。 这是传输过程中主机内存（没有缓冲区和缓存）的平均值，以MB为单位。
内存消耗
Flannel和Kube-router显示了出色的结果-仅50 MB。 Calico和Canal分别有70个。WeaveNet的消耗显然要多于其余的130 MB，而Cilium则消耗多达400 MB。
现在让我们检查CPU使用率。 值得注意的是 ：在图表中，不是百分数，而是百分数，即“裸铁”的含量为38 ppm-为3.8％。 结果如下：
CPU消耗
Calico，Canal，Flannel和Kube-router非常有效地使用CPU-仅比不具有CNI的Kubernetes多2％。 WeaveNet远远落后于其他5％，其次是Cilium-7％。
这是资源消耗的摘要：
总结
表中所有结果：
一般基准结果
结论
在最后一部分中，我将对结果发表我的主观意见。 请记住，该基准测试仅测试非常小的群集（3个节点）上一个连接的吞吐量。 它不适用于大型群集（<50个节点）或并行连接。
我建议根据情况使用以下CNI：
- 群集中的节点资源很少 （几个GB的RAM，几个内核），并且不需要安全功能-选择Flannel 。 这是最经济的CNI之一。 而且它与多种体系结构（amd64，arm，arm64等）兼容。 此外，这是两个CNI（第二个为Cilium）之一，它可以自动确定MTU，因此您无需进行任何配置。 Kube-router也适用，但不是那么标准，您将需要手动配置MTU。
- 如果您需要加密网络以提高安全性，请使用WeaveNet 。 如果使用巨型帧，请不要忘记指定MTU的大小，并通过环境变量指定密码来激活加密。 但是最好不要忘记性能-这是加密费用。
- 对于正常使用，我建议使用Calico 。 该CNI广泛用于各种Kubernetes部署工具（Kops，Kubespray，Rancher等）。 与WeaveNet一样，如果您使用巨型帧，请记住在ConfigMap中配置MTU。 它是一种多功能工具，在资源消耗，生产力和安全性方面均有效。
最后，我建议您跟随Cilium的发展。 这个CNI拥有一支非常活跃的团队，致力于其产品（功能，节省资源，生产力，安全性，集群分发...），并且他们有非常有趣的计划。
CNI选择的可视图