InfoQ|在网易轻舟云原生的应用实践，eBPF( 二 ) eBPF是Linux内核近几年最为引人注目的

Redhat则正在开发一个叫bpffilter的上游项目，将来会替换掉内核里的iptables ，也就是说，内核里基于iptables做包过滤的功能，以后都会用BPF替换。
国内方面腾讯云也对外宣称利用eBPF替换conntrack模块使k8sservice短链接性能提升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(CompileOnce–RunEverywhere)的编译方式，其核心依赖于BTF（更加先进的DWARF替代方案），该方案本文不做展开，感兴趣的同学可自行GoogleCO-RE 。
监控功能的开发：eBPF监控子系统是一个框架，本身不具备任何监控功能。 eBPF监控子系统开发完成后，我们又根据产品方、业务方以及运维方的需求，开发了一些具体的监控功能，例如：
监控HTTP协议的网络请求延迟。因为以往线上业务发生请求超时，我们无法确定延迟是发生在网络传输阶段，还是业务处理阶段，加大了问题排查的复杂度和难度。通过该监控功能，开发运维人员则可以清晰的知道延迟发生的具体阶段，大大缩短了相关问题的排查解决时间。
【InfoQ|在网易轻舟云原生的应用实践，eBPF】

文章图片
监控每个进程中各状态的TCP链接数。在引入eBPF监控之前，我们曾通过inet_diag实现了该监控功能，但是每次读取都是整个系统的全量，对于动辄几十万上百万连接的线上节点，非常占用CPU资源，没办法做到在线的实时监控。引入eBPF后，我们以非常小的代价达到了相同的监控效果，实测QPS性能只有3.7%的下降，对CPU资源的占用可以忽略不计。