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

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

2021-07-07 481

前言

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

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

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

eBPF 是一项革命性技术，它可以以一种安全的方式在内核中许多 hook 点执行程序，该项技术可编程能力强，并且也无需维护内核模块，可维护性好，该项技术为满足上述需求提供了可能。Cilium则是基于 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 社区，与社区一道共同推出更强大、更完善的容器网络能力。

参考资料

【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！

微信关注我们

原文链接：https://my.oschina.net/u/4534936/blog/5123070

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

前端之变（七）：前端的困境

这些年，前端发生了颠覆性的变革，这种变化极大地改变了前端的生态，前端从很多年前一个不起眼的角色跨步式的演变为一个不可或缺的存在。前端的技术不仅是在前端开发本身，它的触角伸向移动开发，后端开发。如果要评选一种全栈式的技术，那后端，移动端本身的一些技术是无法与前端相抗衡的。前端已今非昔比！但是，由于我个人从事了很多年的后端与移动端的开发，在将前端的现状与后端移动端等做对比后，我仍然觉得前端存在一些它自身需要突破的困境。本周，继续就前端阐述自己的思考与分析，这是前端之变系列文章的第七篇，前六篇分别是：前端之变（一）: 技术的变与不变前端之变（二）: "不变"的前端前端之变（三）：变革与突破前端之变（三）：进击的前端前端之变（五）：王者归来前端之变（六）：引领式变革，从命令式UI到声明式UI 写在最开始的话由于是讲前端的困境，所以我希望能做一个简单的申明：前端技术的发展是很快的，本身是非常出色的，这篇文章说的问题，并不是我个人对它的否定，只是基于我个人的全栈式的技术背景下的一些思考这些只是个人的思考，它当然有大概率是错误或偏颇的，但阐述个人的意见也是一件有价值的事。 ...

2021-07-07

590

> 转载请注明出处：葡萄城官网，葡萄城为开发者提供专业的开发工具、解决方案和服务，赋能开发者。在本系列前几篇文章中，我们介绍了从Cloud Foundry到Docker等PaaS平台的发展迭代过程。今天我们继续来为大家介绍Docker走向落寞的原因以及大航海时代的开启。 Docker的商业化上篇中，我们讲到了Docker项目利用自己创新的Docker Image瞬间爆红，于是许多商家也从中发现商机，纷纷推出自己的容器产品，也想在市场中分一杯羹。 CoreOS推出了Rocket（rkt）容器，Google也开源了自己的容器项目lmctfy（Let Me Container That For You）等，但是面对Docker项目的强势，就算是Google这种大佬也毫无招架之力。因此Google打算和Docker公司开展合作，关停自己的容器项目，并且和Docker公司一同维护开源的容器运行，但是Docker公司方面很强势的拒绝了这个明显会削弱自己地位的合作。在这时Docker公司也意识到了，自己仅仅是云计算技术栈中的幕后英雄，只能当做平台最终部署应用的载体。但是，要想成为这个领域...

2021-07-07

496

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。