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

腾讯云原生 • 2023-01-02 • 云技术社区 • 266 阅读

朱瑜坚，腾讯云后台工程师，主要负责腾讯云 TKE 容器网络的构建和相关网络组件的设计、开发和维护工作。
张浩，腾讯云高级工程师，主要负责容器网络多个组件的开发和维护，也关注调度、服务网格等领域。

前言

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

怎么提升网络的可观测性，serverless 类产品该需求尤为突出
怎么尽可能减少容器引入的网络性能损耗

上述需求冲击了 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 自访问问题。