性能测试环境

Pod到Pod的吞吐量和CPU

改善kube-proxy

第一包延迟

保留外部源IP和直接服务器返回

高效的数据平面更新

“技术预览”是什么意思？

结论

性能测试环境

为了进行性能测试，我们使用运行Ubuntu 19.10的物理服务器，这些服务器通过低延迟40Gbit网络连接。40Gbit网络使我们可以运行特别是网络密集型工作负载，与标准Linux网络相比，通常可以在其中看到最大的好处。

Pod到Pod的吞吐量和CPU

我们使用qperf测量在不同节点上运行的一对Pod之间的吞吐量。由于大部分网络开销都是按数据包计算的，因此我们同时测试了1440字节MTU和8940字节MTU（其中MTU是最大数据包大小；对于互联网流量而言，实际值为1500；在某些数据中心中为9000；并且我们都减少了如果您是在重叠式网络的顶部运行，请保守估计为60）。我们测量了吞吐量和CPU使用率。

如您所见，使用8940 MTU，这两个选项都接近饱和40Gbit链路。在较小的数据包大小下，我们看到吞吐量出现了缺口。

请注意，qperf通常将自身限制为单个内核，这使其成为查看CPU数量有限的应用程序可以推送多少流量的好工具。但是重要的是不要误认为该数据是该节点的吞吐量限制，而不是单个qperf实例的吞吐量限制。如果您在多线程应用程序中投入更多的CPU或运行更多的Pod实例，则无论使用哪种数据平面，您都可以使40Gbit链接饱和。

通过标准化每GBit的CPU使用率，eBPF数据平面每GBit的CPU使用量比标准Linux网络数据平面要少得多，在小数据包大小时，获胜最大。

改善kube-proxy

当我们第一次踏上eBPF旅程时，我们并没有计划取代kube-proxy。通常，保持与上游Kubernetes组件的兼容性通常对社区有利。尽管有一些流行的炒作，但kube-proxy使用iptables进行负载平衡对大多数用户来说还是不错的选择。直到您开始扩展到成千上万的服务时，大多数用户才会看到任何明显的性能影响，而对于那些正在运行成千上万的服务的用户，kube-proxy的IPVS模式解决了这些性能问题。

然而，随着我们的进步，我们发现，针对Calico功能的最佳eBPF设计将无法与现有的kube-proxy一起使用，而又不会带来显着的复杂性并降低整体性能。

一旦被迫替换kube-proxy，我们决定看看如何通过本地处理Calico数据平面内的Kubernetes服务来改进上游实施。

第一包延迟

对于kube-proxy和我们的实现，只有新流中的第一个数据包才需要付出代价才能确定该流将被负载均衡到哪个pod。（随后的数据包采用conntrack快速路径，这与您正在运行的服务数量无关。）为了衡量第一个数据包延迟的影响，我们使用curl并打开了详细的调试输出来测量与nginx的“连接时间”。荚。这是进行TCP握手交换的时间（每个方向一个数据包）。

我们改变了服务数量，并在IPVS和iptables模式以及eBPF数据平面中使用kube-proxy进行了测试。

在iptables模式下，kube-proxy的实现使用随服务数量增长的规则列表。因此，随着服务数量的增加，其延迟变得更糟。IPVS模式和我们的实现都使用高效的映射查找，随着服务数量的增加，性能曲线趋于平坦。

将这些数字放在上下文中很重要。尽管IPVS和我们的eBPF模式比其他模式要快，但这只是第一个数据包。如果您的工作量是重新使用连接（例如gRPC或REST API的典型情况）或传输1MB的文件，那么从此更改中节省半毫秒的时间将不会引起注意。另一方面，如果您的工作负载涉及成千上万个短时的，对延迟敏感的连接，那么您将看到真正的收获。（有关此主题的更完整的阅读，探讨了kube-proxy iptables与IPVS模式对现实世界的性能影响，请查看此博客：https ://dev-project-calico-2020.pantheonsite.io/comparing-kube -proxy-modes-iptables-or-ipvs /）

保留外部源IP和直接服务器返回

将网络策略与Kubernetes服务混合在一起的痛点之一是，当进入集群后通过kube-proxy重定向流量时，外部客户端的源IP会丢失。

这意味着入口网络策略和Pod本身都将数据包的源IP视为入口节点，而不是真正的外部客户端。另外，返回流量需要通过原始入口节点返回，因此它可以反转DNAT + SNAT并将流量返回到原始客户端源IP。

（具有externalTrafficPolicy：Local的Kubernetes服务是一个例外，该服务仅在不更改源IP的情况下将负载负载到本地Pod。）

通过我们的eBPF实施，我们可以保留原始源IP，还可以选择执行直接服务器返回（DSR）。也就是说，返回流量可以采用最佳路径，而无需环回原始入口节点。

我们的实施效果如何？下图显示了curl报告的通过节点端口访问nginx服务（服务于标准nginx hello-world页面）时的连接和总时间，其中节点pod位于与入口节点不同的节点上。为了提供一个实际的基准，为此测试配置了1,000个其他服务。

BPF数据平面性能良好，开启直接返回功能可进一步提升性能。

高效的数据平面更新

更新服务时，kube-proxy必须更新内核中的iptables或IPVS状态。使用eBPF，我们能够更有效地更新数据平面。

下图显示了测试过程中整个节点的CPU使用率

从5000个静态服务开始，每个服务有5个Pod支持
睡90秒钟以获得基线
一次仅需花费100秒
睡90s

kube-proxy已配置为其默认的30s最大同步间隔。所有数据平面均配置了1s的最小同步间隔。

正如预期的那样，使用5k服务，与iptables模式下的kube-proxy相比，IPVS模式下的kube-proxy使用更少的CPU来保持数据平面同步。（如果推入更多的服务或服务端点，则两者之间的差距会越来越大。）相反，我们的新eBPF数据平面具有更高效的控制平面，在任何一种模式下，即使在大量的服务。

“技术预览”是什么意思？

我们即将发布的“技术预览”版本的目标是涵盖一系列Calico功能。足以证明这种方法并获得社区的反馈。但是，由于它是技术预览，因此尚未经过我们通常的测试和强化水平，并且存在一些不足和局限性，需要注意：

最重要的是，它还没有准备好投入生产！
eBPF是内核中快速移动的区域。技术预览版需要内核v5.3 +，并且仅在Ubuntu 19.10上进行了测试。
我们尚未实现主机端点或IPv6支持。
当前的实现假定每个节点有一个主机IP，因此不太可能与多宿主设置一起使用。
我们尚未使用IPIP和VXLAN封装模式测试性能。
技术预览版需要Calico IPAM（因此与非Calico CNI不兼容）。
目前，该实现仅限于每个Pod几百条策略规则（尽管对于大多数正常情况而言，这应该绰绰有余）。
MTU处理和ICMP错误报告仅部分实现。

通常，为了获得高性能，我们没有免费的午餐，而是绕过了内核的部分数据包处理逻辑，因此您失去了标准Linux网络的某些灵活性。例如，如果您想添加自己的iptables规则，则很可能会绕过它们以进行pod流量，并且无法按预期运行。

结论

Linux内核的标准网络管道可能会成为未来多年用户和企业的主线选择，而Calico将继续支持它，并提供出色的性能，可伸缩性和可靠性。但是对于那些准备采用较新内核版本的用户，Calico准备将Linux内核的最新网络功能推向极限。

无论哪种选择适合您，您都将获得相同，易于使用的基础网络，网络策略和IP地址管理功能，这些使Calico成为关键任务云原生应用程序最受信任的网络和网络策略解决方案，估计每天为超过一百万个节点供电。

如果您喜欢这篇博客文章，那么您可能还会喜欢：

进行Calico的eBPF数据平面本机服务处理
在projectcalico.org/events上免费进行在线培训，或订阅 Calico Essentials 进行个性化培训和研讨会
了解 Calico Enterprise

介绍Calico eBPF数据平面：Linux内核网络、安全性和跟踪（Kubernetes、kube-proxy）

性能测试环境

Pod到Pod的吞吐量和CPU

改善kube-proxy

第一包延迟

保留外部源IP和直接服务器返回

高效的数据平面更新

“技术预览”是什么意思？

结论

推荐阅读

介绍Calico eBPF数据平面：Linux内核网络、安全性和跟踪（Kubernetes、kube-proxy）相关推荐

最新文章

热门文章