QPS最高提升91% | 腾讯云TKE基于Cilium eBPF提升k8s Service性能

前言

Kubernetes已经成为容器管理领域的事实标准，而网络系统是Kubernetes核心部分，随着越来越多的业务部署在Kubernetes，对容器网络也提出了一些新的需求

1.怎么提升网络的可观测性，serverless类产品该需求尤为突出

2.怎么尽可能减少容器引入的网络性能损耗

上述需求冲击了iptables，IPVS等传统防火墙，负载均衡器技术。也促使我们思考容器网络访问链路能否不依赖于节点，进而缩短容器访问链路，提升网络性能

eBPF是一项革命性技术，它可以以一种安全的方式在内核中许多hook点执行程序，该项技术可编程能力强，并且也无需维护内核模块，可维护性好，该项技术为满足上述需求提供了可能。Cilium[1]则是基于eBPF技术的容器网络开源项目，提供了网络互通，服务负载均衡，安全和可观测性等解决方案

由此，腾讯云容器服务TKE基于Cilium和eBPF实现了独立网卡模式下的高性能ClusterIP Service方案。TKE致力于提供更高性能、更安全和更易用的容器网络，也因此会不断关注Cilium等前沿的容器网络技术方案，后续会推出更多更完善的Cilium产品化能力。

独立网卡Service方案

TKE于去年推出了新一代容器网络方案，该方案实现了一个Pod独占一张弹性网卡，不再经过节点网络协议栈（default namespace）。而当前的kube-proxy实现ClusterIP的方案都依赖于在节点侧的网络协议栈里设置相应的iptables规则，也因此该方案对于独立网卡方案不再适用。

其中一个解决方案便是Cilium，Cilium提供了基于eBPF的地址转换能力，从而可支持ClusterIP Service。但其原生方案仅支持veth pair和ipvlan l3的数据面，并不支持Pod完全不经过节点网络协议栈的数据面，因此不能原生解决独立网卡ClusterIP的访问问题。

TKE由此对Cilium加以改造，使其支持了除原生支持的veth和ipvlan l3的第三种数据面方案，如图（假设pod访问Service IP为172.16.0.2），数据面上，将原本挂载到节点侧的veth上的bpf程序，挂载到pod内的独立网卡（同时也是弹性网卡）上，使得Pod的网络报文在发出的时候做DNAT（目的地址转换），而回报文在网卡接收的时候做反向DNAT，从而支持ClusterIP的访问。该数据面方案可作为一个通用方案适配Ipvlan l2、SRIOV等数据面场景。

而控制面上，将Cilium与TKE的VPC-CNI模式（含共享网卡模式和独立网卡模式）深度集成，用户无需对业务代码逻辑做任何修改，即可使用Cilium的功能特性。

性能对比

本文使用wrk工具对Cilium的产品化解决方案进行了性能压测，测试保证Client Pod和Server Pod分布在不同节点。

测试环境：TKE集群，4个CVM节点，配置为Server S5.2XLARGE8，Client S5.SMALL2。

测试数据表明，基于Cilium的独立网卡ClusterIP访问方案性能最好。在短连接场景下，其QPS相比共享网卡的iptables和ipvs方案提升48%和74%，相比全局路由的iptables和ipvs方案提升了62%和91%。在长连接场景下，其QPS相比共享网卡的iptables和ipvs方案提升了33%和57%，而相比全局路由的iptables和ipvs方案提升了49%和66%。iptables的性能较ipvs性能较好是因为测试环境中Service数量还不够多，ipvs的优势在于大量Service的场景。

产品化过程中的相关问题

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

独立网卡方案下的ClusterIP自访问不通

以上方案其实不能完全解决ClusterIP访问问题，存在一类特殊的场景会访问不通。这类场景就是Pod访问的ClusterIP，其后端包括其自身。这类场景下，独立网卡的Pod发出的网络报文会直接到达IaaS层，不符合预期。

由于独立网卡Pod内，其实只有两个网络设备：回环设备（lo）和弹性网卡，因此一个简单的思路就是在出报文之前，对自访问流量，通过bpf_redirect调用将报文直接转发（redirect）到回环（lo）设备。基于此，TKE团队修改了cilium的相关bpf代码，提供了一个解决方案。经过测试，该方案可以解决独立网卡方案下的ClusterIP自访问问题。

Cilium加载bpf程序的名字缺失

Cilium项目的可调试性存在一个问题，其bpf程序开发得比较早，底层用了很多老的工具集，例如tc，来加载bpf代码。

老的tc基于老的内核版本(<4.15)设计的，它在加载bpf程序时，将bpf程序的名字忽略了，导致Cilium加载的bpf程序都是无名字的。这影响了对代码的理解，追踪和调试。

对此TKE团队结合较新的内核对tc工具进行了修正，使得它加载bpf程序时，会正确的传入名字。通过这名字，可以搞清楚实际运行的bpf函数具体是哪一个，从而提高Cilium的可调试性。

用法

申请Cilium支持ClusterIP产品化内测开通后，创建TKE集群时高级设置中打开ClusterIP增强即可：

总结与展望

本文介绍了TKE团队实现的基于Cilium和eBPF的独立网卡模式下高性能ClusterIP service方案，该方案相比当前基于iptables和ipvs的传统网络方案大量的提升了性能（33%-91%）。

显然，Cilium提供的能力还不止于此，其基于eBPF这项革命性的技术，还提供了安全、可观测性、QoS等方面的能力，而提供更高性能、更安全和更易用的容器网络正是TKE的服务目标，因此，后续TKE将会积极参与Cilium社区，与社区一道共同推出更强大、更完善的容器网络能力。

参考资料

[1] Cilium项目官网:【https://cilium.io/】

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

[3] Kubernetes Service:【https://kubernetes.io/docs/concepts/services-networking/service/】

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