InfoQ|eBPF 在网易轻舟云原生的应用实践( 二 )

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 监控子系统开发完成后，我们又根据产品方、业务方以及运维方的需求，开发了一些具体的监控功能，例如：