QPS最高提升91% 腾讯云TKE基于Cilium eBPF提升k8s Service性能,腾讯云tke 容器实战-ESG跨境

QPS最高提升91% 腾讯云TKE基于Cilium eBPF提升k8s Service性能,腾讯云tke 容器实战

QPS高达91% 腾讯云TKE基于纤毛eBPF提升k8s服务性能

前言

Kubernetes已经成为集装箱管理领域事实上的标准，网络系统是Kubernetes的核心部分。随着越来越多的业务部署在Kubernetes，对集装箱网络提出了一些新的要求。

1.如何提高网络的可观测性，无服务器产品的需求尤为突出。

2.如何最大限度地减少容器对网络性能的损失

上述需求冲击引入了传统的防火墙和负载平衡器技术，如iptables和IPVS。这也促使我们考虑容器网络访问链路是否可以独立于节点，从而缩短容器访问链路，提高网络性能。

EBPF是一项革命性的技术，它可以安全地在内核的许多钩子点执行程序。该技术可编程性强，无需维护内核模块，可维护性好。这项技术为满足上述要求提供了可能性。ciu[1]是基于eBPF技术的容器网络开源项目，提供网络互操作、服务负载均衡、安全性和可观测性等解决方案。

因此，腾讯云容器服务TKE基于Cilium和eBPF实现了独立网卡模式下的高性能ClusterIP服务方案。TKE致力于提供更高性能、更安全和更易于使用的集装箱网络。因此，TKE将持续关注纤毛等前沿的集装箱网络技术解决方案，未来将推出更多更完善的纤毛产品化能力。

独立网卡服务方案

TKE去年推出了新一代的容器网络方案，实现了一个Pod独占一个弹性网卡，无需经过节点网络协议栈(默认命名空间)。但是目前针对ClusterIP的kubeproxy解决方案都依赖于在节点侧的网络协议栈中设置相应的iptables规则，所以这种解决方案不再适用于独立网卡解决方案。

解决方案之一是Cilium，它提供基于eBPF的地址翻译能力，从而支持ClusterIP服务。但其原生解决方案只支持veth pair和ipvlan l3的数据平面，完全不支持Pod不通过节点网络协议栈的数据平面，因此无法原生解决独立网卡ClusterIP的接入问题。

TKE由此改造了Cilium，使其支持除了原生支持的veth和ipvlan l3之外的第三种数据平面方案，如图所示(假设pod接入服务IP为172.16.0.2)。在数据平面上，原本挂载在节点侧veth上的bpf程序挂载在pod中的独立网卡(也是弹性网卡)上。它使得Pod的网络报文在发出的时候做DNAT(目的地址转换)，返回的报文在网卡收到的时候做反向DNAT，从而支持ClusterIP访问。该数据平面方案可以用作通用方案，以适应Ipvlan l2、SRIOV和其他数据平面场景。

在控制端，Cilium与TKE的VPCCNI模式(包括共享网卡模式和独立网卡模式)深度融合，用户无需对业务代码逻辑做任何修改，即可使用Cilium的功能特性。

性能比较

本文使用wrk工具对Cilium的产品化解决方案进行性能测试，测试确保客户端Pod和服务器Pod分布在不同的节点。

测试环境:TKE集群，4个CVM节点，配置为服务器5.2个大8，客户端5.2个小2

测试结果表明，基于纤毛的ClusterIP接入方案性能最佳。在短连接场景下，其QPS比共享网卡的iptables和ipvs方案分别提高了48%和74%，比全局路由的iptables和ipvs方案分别提高了62%和91%。在长连接场景下，其QPS比共享网卡的iptables和ipvs方案分别提高了33%和57%，比全局路由的iptables和ipvs方案分别提高了49%和66%。iptables的性能优于ipvs是因为测试环境中没有足够的服务，而ipvs的优势在于大量服务的场景。

产品化过程中的相关问题

TKE团队在实现Cilium产品化解决方案的过程中也发现了Cilium项目中的一些问题，相应的解决方案和Cilium支持新数据平面计划将于近日以pr的形式提交给Cilium社区。

ClusterIP自访问在独立网卡方案下被阻止

事实上，上述解决方案并不能完全解决ClusterIP访问的问题，有一种特殊的场景会阻止访问。这种场景就是Pod访问的ClusterIP，它的后端包括它自己。在这种场景下，独立网卡的Pod发快递的网络消息会直接到达IaaS层，不符合预期。

由于独立网卡Pod中实际上只有两个网络设备:loopback device (lo)和elastic网卡，一个简单的思路就是在发快递消息之前，通过bpfredirect调用直接将自接入流量重定向到loopback device。基于此，TKE团队修改了纤毛的相关bpf代码并提供了解决方案。经过测试，该方案可以解决独立网卡方案下的ClusterIP自访问问题。

缺少加载bpf程序的纤毛的名称

Cilium项目的调试中存在问题。它的bpf程序开发的比较早，很多老的工具集，比如tc，都是用在底层加载bpf代码。

老tc基于老内核版本(lt；4.15)设计上，它在加载bpf程序时忽略了bpf程序的名称，导致所有由Cilium加载的bpf程序都是无名的。这会影响对代码的理解、跟踪和调试。

为此，TKE团队结合更新的内核修改了tc工具，这样当它加载bpf程序时，它将正确地传入名字。通过这个名字，我们可以发现实际运行的是哪个bpf函数，从而提高Cilium的调试。

用法

申请Cilium支持开启ClusterIP产品化内测后，创建TKE集群时，在高级设置中开启ClusterIP增强:

总结和展望

介绍了TKE团队实现的基于Cilium和eBPF的独立网卡模式下的高性能ClusterIP服务方案，与目前基于iptables和ipv的传统网络方案相比，性能大幅提升(33%91%)。

显然，Cilium提供的功能不止于此。基于eBPF这一革命性技术，它还提供了安全性、可观察性、QoS等能力。，而提供更高性能、更安全和更易用的集装箱网络是TKE的服务目标。因此，后续TKE将积极参与纤毛社区，与社区共同推出更强更好的容器网络能力。

参考数据

[1]纤毛工程官网:[https://cilium.io/]

[2] eBPF介绍和参考指南:[https://docs.cilium.io/en/v1.10/bpf/]

[3] Kubernetes服务:【https://Kubernetes . io/docs/concepts/servicesnetworking/Service/】

[4]腾讯云容器服务TKE推出新一代零损耗容器网络。

特别声明：以上文章内容仅代表作者本人观点，不代表ESG跨境电商观点或立场。如有关于作品内容、版权或其它问题请于作品发表后的30日内与ESG跨境电商联系。