K8S/Kubernetes

 

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

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

 

缩放结果的解释

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

 

MTU设置对带宽性能的影响

以下是设置结果的摘要：

 

设置基准测试结果摘要

安全

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

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

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

以下是结果摘要：

 

安全基准测试结果摘要

性能

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

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

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

结果如下：

 

TCP性能

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

 

UDP性能

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

 

HTTP性能

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

FTP性能

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

SCP表现

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

以下是CNIs表现的总结：

 

表现基准测试结果摘要

资源消耗

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

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

 

平均节点RAM使用率（无缓冲区/缓存）

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

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

 

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

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

 

资源消耗总结

摘要

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

 

所有结果的快速摘要

结论

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

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