Kubernetes 网络插件在超过 10Gbit/s 下的基准测试结果

概览

在运行 Kubernetes 1.19 和 Ubuntu 18.04 上进行基准测试

在我们深入讨论度量之前
CNI 经过 MTU 调优
CNI 基准:原始数据
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/icyxp/benchmark-k8s-cni-2020-08

1.2 基准协议

整个协议详见：https://github.com/icyxp/benchmark-k8s-cni-2020-08/blob/master/PROTOCOL.md

请注意，当前的文章只关注 Ubuntu 18.04 的默认内核。

1.3 选择 CNIs 做基准测试

这个基准测试旨在比较可以用单个 yaml 文件设置的 CNIs（因此排除所有基于脚本的安装，如基于 VPP 的 CNIs 等）。

我们将比较的 CNIs 列表如下：

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 调优

首先，我们将检查 MTU detection 对 TCP 性能的影响：
MTU impact on TCP performance

UDP 的缺点更加明显：
MTU Impact on UDP performance

考虑到这里所揭示的对性能的巨大影响，我们希望向所有 CNI 维护者传达一个希望的消息：请在CNIs 中实现 MTU auto-detection。你将会拯救小猫，独角兽，甚至是最可爱的一个: devops 小家伙！

然而，如果您确实必须选择一个没有实现 auto-MTU 的 CNI，那么您需要自己对它进行调优以保持性能。请注意，这适用于 Calico，Canal 和 Weavenet。
My little message to CNI maintainers ….

3 CNI基准：原始数据

在本节中，我们将比较 CNI 和正确的 MTU（auto-detected 或手动调优）。这里的主要目标是在图表中显示原始数据。

颜色代码：

灰色 : 参考 (裸机)
绿色 : 带宽 > 9500 Mbit/s
黄色 : 带宽 > 9000 Mbit/s
橙色 : 带宽 > 8000 Mbit/s
红色 : 带宽 < 8000 Mbit/s
蓝色 : 中性 (与带宽无关)

3.1 Idle

首先要建立 CNI 消耗，当整个集群….像是在休眠？
Idle resource consumption

3.2 Pod-to-Pod

在这个场景中，客户端 Pod 直接连接到服务器 Pod 的 IP 地址。
Pod-to-Pod scenario

3.2.1 TCP

“Pod-to-Pod” TCP 相关资源消耗结果如下:
pod-to-pod tcp

3.2.2 UDP

“Pod-to-Pod” UDP 相关资源消耗结果如下:
pod-to-pod udp

3.3 Pod-to-Service

在本节中，客户端 Pod 通过 ClusterIP Service 连接到服务端 Pod。这与实际的用例更相关。
Pod-to-Service scenario

3.3.1 TCP

“Pod-to-Service” TCP 相关资源消耗结果如下:
pod-to-service tcp

3.3.2 UDP

“Pod-to-Service” UDP 相关资源消耗结果如下:
pod-to-service udp

3.4 网络策略

在此基准测试中所列出的所有 CNIs 中，唯一不完全支持网络策略的是 Flannel。所有其他的都正确地实现了网络策略，包括入口和出口。做得好!

4 CNI 加密

在我们测试的所有 CNIs 中，以下是能够加密 pod 间通信：

Antrea with IPsec
Calico with wireguard
Cilium with IPsec
WeaveNet with IPsec

4.1 带宽

由于在这场对比中 CNIs 较少，因此让我们在一张图中概况所有场景：
encryption

4.2 资源消耗

在本节中，我们将研究 Pod-to-Pod 通信所使用的资源，包括 TCP 和 UDP。在这里显示 Pod-to-Service 的图没有意义，因为它没有提供更多信息。
encryption-tcp
encryption-udp

5 总结

让我们尝试回顾一下这些图表。我们在这里引入了一点主观性，用修饰符替换了实际值，如“非常快”、“低”等。
Benchmark result summary (August 2020)

6 结论 - 我的结论

最后一部分是主观的，表达了我自己对结果的理解。

我很高兴看到 CNI 的新成员加入进来。Antrea 在游戏中表现得很好，它提供了许多特性，甚至在早期版本中也有：auto-mtu、加密选项和直接安装。

考虑到性能，除了 Kube-OVN 和 Kube-Router 之外，所有 CNIs 都表现的很好。关于 Kube-Router，它无法检测到 MTU，而且我在文档中找不到调优它的方法（这里有一个关于 MTU 配置的 open issue）。

在资源消耗方面，Cilium 仍然比竞争对手使用更多的 RAM，但该公司公开目标是大规模集群，这与在这个 3 节点基准的情况不完全一样。Kube-OVN 也是 RAM 和 cpu 密集型的，它仍然是一个相当年轻的 CNI，它依赖于 Open vSwitch (Antrea 也是，但 Antrea 更轻，性能更好)。

网络策略由所有测试的 CNIs 实现，Flannel 除外。Flannel 很可能永远不会（永远）实现它，因为他们的目的很明确：越轻越好。

此外，加密性能在这里是真正的 “哇效果”。Calico 是最古老的 CNIs 之一，但他们直到几周前才提供加密服务。他们更喜欢 wireguard 而不是 IPsec，而且至少可以说，它在这一领域的表现是伟大的，惊人的，完全优秀的对于其他 CNIs。当然，由于加密负载，它会消耗大量 CPU，但它们所实现的带宽是完全值得的（记住，Calico encrypted perf 大约比Cilium 好 6 倍，后者排名第二）。此外，在集群上部署 Calico 之后，您还可以随时激活 wireguard 加密，您也可以暂时禁用它，或者永远禁用它。这是难以置信的对于用户友好度。但是！我们提醒您，Calico 目前还不能 auto-detect MTU（该特性计划很快发布），因此，如果您的网络支持巨型帧（MTU 9000），请不要忘记调整 MTU。

此外，请注意，Cilium 能够加密整个节点到节点的通信（不仅仅是 pod 通信），这对于面向公共的集群节点来说可能是一个非常有吸引力的特性。

总结一下，这是我对以下用例的建议：

我需要一个 CNI 来容纳额外的小型节点集群，或者我不关心安全性

选用 Flannel，这是最轻最稳定的 CNI。
(它也是最古老的之一。根据传说，它是由 Homo-Kubernautus 或 Homo-Containorus 发明的。您可能会对精彩的 k3s 项目感兴趣！点击这里查看详情！

我的标准群集需要一个 CNI

好的，Calico 是你的选择，如果有必要的话，不要忘记调整 MTU。您可以使用网络策略，轻松启用/禁用加密，等等。

我的（非常）大型集群需要一个 CNI

好吧，该基准测试无法反映大型集群的行为。我很乐意为此工作，但是我们没有数百台具有 10Gbit/s 连接性的服务器。因此，最好的选择是至少使用 Calico 和 Cilium 在您的节点上运行自定义的基准测试。

感谢阅读！

作者：Alexis Ducastel 来源：medium.com

微信订阅号