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

https://my.oschina.net/cncf/blog/5121393

朱瑜坚，腾讯云后台工程师，主要负责腾讯云 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 自访问问题。

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 社区，与社区一道共同推出更强大、更完善的容器网络能力。