eBPF是Linux内核近几年最为引人注目的特性之一，通过一个内核内置的字节码虚拟机，完成数据包过滤、调用栈跟踪、耗时统计、热点分析等等高级功能，是 Linux系统和Linux应用的功能/性能分析利器。本文将介绍eBPF的技术特点，及eBPF在网易杭研轻舟系统探测和网络性能优化方面的应用。

1. 技术浅析—eBPF好在哪里

eBPF是Linux Kernel 3.15中引入的全新设计，将原先的BPF发展成一个指令集更复杂、应用范围更广的“内核虚拟机”。

eBPF支持在用户态将C语言编写的一小段“内核代码”注入到内核中运行，注入时要先用llvm编译得到使用BPF指令集的ELF文件，然后从ELF文件中解析出可以注入内核的部分，最后用bpf_load_program()方法完成注入。用户态程序和注入到内核中的程序通过共用一个位于内核中的eBPF MAP实现通信。为了防止注入的代码导致内核崩溃，eBPF会对注入的代码进行严格检查，拒绝不合格的代码的注入。

1.1 eBPF的技术优势

eBPF具备一些非常棒的特性，使得我们在内核层面的监控变得更加便捷、高效，并且非常安全：

平台无关，由JIT负责将BPF代码翻译成最终的处理器指令；
内核无关，辅助函数（Helper functions）使得BPF能够通过一组内核定义的函数调用（Function call）来从内核中查询数据，或者将数据推送到内核。不同类型的 BPF 程序能够使用的辅助函数可能是不同的；
安全检查，和内核模块不同，BPF程序会被一个位于内核中的校验器（in-kernel verifier）进行校验，以确保它们不会造成内核崩溃、程序永远能够终止等；
方便升级，对于网络场景（例如TC和XDP），BPF程序可以在无需重启内核、系统服务或容器的情况下实现原子更新，并且不会导致网络中断；
通信方式，eBPF MAP，跟Ftrace提供的ring buffer相比就是数据常驻内存，不会读取之后就消失；
-事件驱动，BPF 程序在内核中的执行总是事件驱动的；

1.2 eBPF和其他trace工具的对比

在eBPF出现之前，Linux已经存在多种成熟的trace机制和相应的上层工具：

如上图所示，eBPF借助perf_event和trace_event几乎支持对目前所有已知trace功能的支持，唯一与传统trace工具不同的是，attach到每个探测点的probe函数是运行在JIT虚拟机上的eBPF程序，具备上面提到平台无关、内核无关、安全等一系列更优的特性。

2 热点追踪—eBPF有哪些应用场景

eBPF应用主要分为两个场景，一是系统探测、二是网络方面性能优化（包括数据面传输和规则匹配等场景）。

2.1 在系统探测方面

在国外，Google已经开始用BPF做profiling，找出在分布式系统中应用消耗多少CPU。而且，他们也开始将BPF的使用范围扩展到流量优化和网络安全。

在国内，字节跳动利用eBPF技术开发了一款名为sysprobe的监控工具，用来定位分析线上业务的性能瓶颈等。

基于eBPF开源的探测工具推荐两个：

BCC是eBPF的一个外围工具集，使得 “编写BPF代码-编译成字节码-注入内核-获取结果-展示” 整个过程更加便捷。此外BCC项目还有一个非常丰富的探测工具集合。
Bpftrace可以理解为是eBPF的高级追踪语言，动态的翻译这些语言，生成eBPF后端程序并通过BCC工具实现和Linux BPF系统进行交互。

2.2 在网络性能优化方面

Facebook用BPF重写了他们的大部分基础设施。例如使用BPF替换了iptables和network filter，并且Facebook 基本上已经将他们的负载均衡器从IPVS换成了BPF，此外他们还将BPF用在流量优化（traffic optimization）、网络安全等方面。

Redhat 则正在开发一个叫bpffilter的上游项目，将来会替换掉内核里的iptables，也就是说，内核里基于iptables做包过滤的功能，以后都会用BPF替换。

国内方面腾讯云也对外宣称利用eBPF替换conntrack模块使k8s service短链接性能提升40%。

3. 牛刀小试—eBPF在网易轻舟的应用及落地

eBPF在网易轻舟的应用也分为系统探测和网络性能优化两个方面。

3.1 系统探测

我们现有监控工具只能监控内核主动暴漏的数据，存在监控盲点。通过修改内核或开发内核模块的方式进行监控，上线周期长、风险高，针对不同版本内核的适配费时费力还容易出错。所以我们在开源项目ebpf_exporter的基础上完成ebpf监控子系统的开发。

eBPF监控子系统架构：

eBPF监控子系统采用容器化部署，支持通过K8s部署和管理，监控数据通过Prometheus进行持久化存储并通过Grafana进行展示。eBPF监控子系统具备如下特性：

平台无关且内核无关；
安全检查以保证绝对安全；
可对内核进行任意监控；
支持pid/container/pod级别的细粒度监控；
支持监控项动态开启、关闭；
支持监控项在线升级；
提供统一的监控项开发接口；
提供metrics/json格式的监控数据及统一的数据获取接口;
支持K8s部署、管理；

关于eBPF“内核无关”特性的说明：

上述特性中，“平台无关”由eBPF机制自身提供（JIT），而内核无关这一特性则受多方面因素的影响，受限内核无关分为两个方面：

内核类型和数据结构是不断变化的，包括函数接口，eBPF程序对内核的引用如何保证在不同版本内核中有效；
不同版本内核的内存布局也是不同的，具体信息必读从独立的内核环境中才能获得；

针对内存布局这个问题，目前我们无需多虑。因为ebpf_exporter是基于BCC技术实现的，而BCC则是通过即时编译的方式加载eBPF程序，基于BCC唯一的缺点就是每次加载会占用一些资源，多少取决于监控程序的数量和复杂度。

针对第一个问题（即kernel代码一直在变的问题），内核中的eBPF机制抽象了一组有限的“稳定的接口”，这些接口屏蔽了不同内核版本之间的差异，但这只是一组有限的接口，如果出于需求eBPF程序对内核耦合过深，我们依然需要通过#if#else来迎合不同版本内核之间的差异（例如数据结构和函数接口的差异）。

所以eBPF的内核无关是有限的，需要eBPF机制和开发者共同努力实现。此外除了BCC这种即时编译的方案，还有另外一种名为CO-RE (Compile Once – Run Everywhere)的编译方式，其核心依赖于BTF（更加先进的DWARF替代方案），该方案本文不做展开，感兴趣的同学可自行Google CO-RE。

监控功能的开发：

eBPF监控子系统是一个框架，本身不具备任何监控功能。eBPF监控子系统开发完成后，我们又根据产品方、业务方以及运维方的需求，开发了一些具体的监控功能，例如：

监控HTTP协议的网络请求延迟。因为以往线上业务发生请求超时，我们无法确定延迟是发生在网络传输阶段，还是业务处理阶段，加大了问题排查的复杂度和难度。通过该监控功能，开发运维人员则可以清晰的知道延迟发生的具体阶段，大大缩短了相关问题的排查解决时间。

监控每个进程中各状态的TCP链接数。在引入eBPF监控之前，我们曾通过inet_diag实现了该监控功能，但是每次读取都是整个系统的全量，对于动辄几十万上百万连接的线上节点，非常占用CPU资源，没办法做到在线的实时监控。引入eBPF后，我们以非常小的代价达到了相同的监控效果，实测QPS性能只有3.7%的下降，对CPU资源的占用可以忽略不计。
开发了cpucycles/instructions、llcreferences/misses等一系列针对硬件PMU的监控功能用来支持混合部署中的调度功能。

更多的监控功能就不一一列举了，除了自研的一些监控，我们还将BCC工具集中一些功能引入了进来，目前主要用来支撑自动诊断、监控报警、性能调优等场景。

eBPF开发中遇到的问题：

一直都在陈述eBPF的优点，但是在开发具体监控功能的过程中，依然存在诸多限制，包括内核实现方面的限制也有eBPF自身的一些限制，需要开发者充分的考虑，例如在多核平台上如何保证对eBPF MAP中数据修改操作的原子性、如何将监控数据与产生数据的进程关联起来等等。

有些问题我们可以解决，但是也有些问题我们目前也没找到好的解决方法，例如将监控数据与产生数据的进程关联起来这个问题，这是一个非常常见的问题，通常由内核的实现逻辑引入，该问题我们在监控TCP连接状态变化的场景中（连接建立过程不在进程上下文），通过记录socket创建以及socket继承等操作得到了解决，但是在Block IO相关的监控场景中就没那么好解决了，我们依然在这方面不断探索。

3.2 网络性能优化

在网络性能优化方面，网易轻舟也基于ebpf的sockmap和sk redirect功能研发了自己的sockops组件，主要用于加速istio架构中sidecar代理和本地进程之间的通信。

Sockops技术原理说明：

Sockmap是eBPF提供的一个特殊的eBPF MAP类型，主要用于socket redirection，在socket redirection中，socket被添加到sockmap中并由key（主要是四元组）引用，然后该socket在调用bpf_sockmap_redirect（）时进行重定向。

sockops的技术原理如下图所示，对于本地通信可以绕过TCP/IP协议栈将报文直接发给对端socket，以此来提高性能。Sockops组件技术原理如下图所示：

Sockops数据面对轻舟服务网格场景的适配：

如果一个报文的key（主要是四元组）在sockmap中被命中，那么该报文将绕过TCP/IP协议栈，而被直接发送给接收端的socket，接收端的socket对应的就是下图中sockmap的value所存储的skops结构。

首先我们监听TCP链接状态的变化，在连接建立时，填充sockmap。然后我们再通过eBPF的sk_msg功能hook TCP的发包流程（sendmsg/sendfile等），并在hook函数中调用bpf_sockmap_redirect（）对socket进行重定向。

不过在istio环境中，该情况会变得稍微复杂一些，因为istio通过iptables redirect将pod访问svc的报文重定向到 envoy，加之sockmap的捕捉是在iptable规则之前，所以sockmap 捕捉到的反向连接跟正向连接的源、目的地址不是一一对应的，找不到正向连接信息。我们的解决方案是新增一个eBPF MAP，并在正向连接建立时，以源地址为key，目的地址作为value存储起来，反向连接建立时根据反向链接的目的地址可以直接找到正向连接的完整信息。用一张图可以比较清晰的看懂这个过程：

Sockops组件完整的架构设计如下图所示：

主要分为用户态DaemonSet程序和运行在内核中的eBPF程序两部分组成：

用户态DaemonSet程序，主要负责一些管控面的操作，包括监控K8S、docker的一些信息或者事件，然后动态更新eBPF程序的配置（用来支持细粒度开启关闭sockops功能），还包括编译加载eBPF程序、提供整个sockops组件的升级、对接prometheus提供自身的一些监控信息等功能；
内核态eBPF程序，则主要负责上面讲到的全部数据面的加速功能，并根据用户态DaemonSet程序同步的配置，具体实现一个细粒度的scokops功能的开启关闭；

Sockops组件加速调优结果：

最终，我们通过sockops组件加速，envoy单worker情况下：

both sidecar时延降低约15-20%，qps提高约20%；
client sidecar时延降低约10%，qps提高约20%；

4 未来展望

在系统探测方面，目前我们仅仅是通过eBPF解决了一些迫切的问题，这些问题通过常规的监控手段无法做到或者代价高昂。随着eBPF监控在内部的应用，我们还会逐步通过eBPF监控替换掉以往一些比较重的、对上层应用侵入比较深的监控功能，一来可以提高监控模块的性能，二来也提高了监控模块的可运维性。此外我们仍在开发一些相对复杂的eBPF监控功能，这些监控功能结合自动诊断平台，可以协助开发运维人员或者直接自动发现一些线上排查起来非常繁琐的问题，以此提高上层产品的SLA保障水平。

在网络性能优化方面，我们有一些对iptables依赖较重的场景（例如kube-proxy），我们会利用eBPF并结合社区的一些成果，给出性能优化方案及原型的开发验证。目前已经有很多非常好的开源项目，提供了类似的功能，代表性的如cilium，我们也针对cilium做了一系列验证，在性能及功能方面并未达到我们的预期，所以我们决定还是从我们自身的需求入手，借助社区已有的成果自研一个轻量级的组件来满足需求。

作者简介：

李阳，网易杭州研究院轻舟云原生系统资深开发工程师，7年开发经验，曾就职于绿盟科技和360安全研究院，专注于linux内核开发、系统和网络安全及性能调优。目前在网易杭研负责虚拟化网络数据面的性能调优工作。

陈启钧，网易杭州研究院轻舟云原生资深开发工程师，十年以上开发经验，曾就职于华为，主要从事存储网络管理、容器以及网络虚拟化相关工作，专注于发现并解决问题。目前在网易杭研主要负责VPC网络、轻舟容器网络、轻舟服务网格等方面的性能调优工作，主要关注Kubernetes、eBPF/XDP、用户态协议栈相关技术。

创作场景

eBPF 在网易轻舟云原生的应用实践