28 年度总结：eBPF的2024之旅

你好，我是倪朋飞。

时光飞逝，2024 年已悄然接近尾声。每当岁末，我都习惯回顾这一年的旅程，细细品味那些发生的事情、收获的喜悦，以及留下的遗憾。这样的回顾让我对未来充满期待，希望能够减少遗憾，增添更多收获。

同样，eBPF 的发展历程也值得我们驻足回顾。在今天的课程中，我将带你一同回顾 eBPF 在 2024 年的精彩旅程，探索这一年里 eBPF 领域发生的重要事件，盘点取得的显著成果，并展望未来的发展方向。让我们一起回顾过去，展望未来，见证 eBPF 技术的蓬勃发展。

eBPF 内核的新进展

作为 Linux 内核的一部分，让我们先来看看 eBPF 在 2024 年中有哪些新变化。

2024 年，Linux 内核发布了 6.7 至 6.12 这六个重要版本，每个版本都为 eBPF 引入了众多新特性。具体来说，这几个版本的主要亮点包括以下几点。

Linux 6.7：异常处理和可编程网络设备

Linux 6.7 通过新增的 bpf_throw() 和 bpf_set_exception_callback() 接口为 eBPF 添加了异常处理支持，允许 eBPF 程序在遇到无法处理的情况时安全终止，并通过回调函数返回。异常处理主要用于在 eBPF 程序中实现断言，确保程序在不满足特定条件时安全退出，并使内核验证器能够利用这些断言来优化程序的执行。

除了异常处理的支持之外，Linux 6.7 还引入了一个专为容器设计的 eBPF 可编程网络设备 Netkit，用来取代传统的虚拟网卡对（veth pair），从而将容器网络的性能提升到跟主机性能几乎一致。

Linux 6.8：安全性和性能优化

Linux 6.8 引入了文件验证机制（包括 LSM 和 fsverity 支持），改善了 eBPF 验证器，降低了全局内存分配器的内存使用，并移除了 bpfilter（将在 Github 继续维护）。

Linux 6.9：Arena 和 Token

Linux 6.9 带来了两个重要特性，大大增强了 eBPF 的灵活性：

eBPF arena 提供了 eBPF 程序和用户空间之间共享的稀疏内存区域，可以用于更高效的数据交换；
eBPF token 允许特权系统守护程序通过特殊挂载选项将 eBPF 子系统的部分功能委托给受信任的非特权应用程序，从而使容器化的 eBPF 应用程序能够在用户命名空间中使用。

Linux 6.10：工作队列和 KRPOBE 会话

Linux 6.10 带来了三个重要特性，进一步增强了 eBPF 程序的灵活性：

第一，新增了工作队列，允许 eBPF 程序调度任务以异步执行；
第二，新增了 KPROBE 会话，允许 eBPF 程序同时挂载到入口跟踪点和返回跟踪点；
第三，支持在 eBPF 程序中禁用抢占。

Linux 6.11：性能提升和追踪增强

Linux 6.11 添加了一个新的 uretprobe 系统调用，使 uretprobe 的速度提高了 10% -30%（暂时只在 x86_64 上实现）。

此外，Linux 6.11 还支持了从 BTF 导出 kfunc 原型，并允许多个用户进行函数图追踪（function graph）。

Linux 6.12：可扩展调度器

Linux 6.12 引入了可扩展调度器类 (sched_ext)，这是一个重要的创新，使得开发者可以在 eBPF 中编写任务调度算法，从而提供更快的开发迭代并实现任务调度的个性化。

伴随着这些内核版本的发布，eBPF 的安全、性能和灵活性方面都有了显著提升，特别是异常处理、Arena、Token 以及可扩展调度器等新特性尤其值得你关注。

伴随着这些新功能特性的引入，与 Linux 内核 eBPF 配套的开发库 libbpf 和命令行工具 bpftool 也都集成了这些新的功能特性。你可以访问它们的 Github 发布网站，查看最新的发布列表。

与此同时，在开源社区和商业公司的推动下，eBPF 的生态也在蓬勃发展。接下来，我们再一起来探索开源社区和商业公司为 eBPF 生态系统带来的最新进展。

eBPF 生态的新进展

如果说 2023 年的 eBPF 生态是遍地开花，那么 2024 年的 eBPF 生态则可谓是进入了蓬勃发展的新阶段。2023 年，许多公司和开源社区将 eBPF 作为核心技术应用到产品中。而到了 2024 年，eBPF 已成为云原生、网络、安全和可观测性等领域不可或缺的基础设施，其应用深度和广度都达到了新的高度。

在网络领域，Cilium 的发展依旧令人瞩目。它不仅利用 eBPF 取代了 iptables kube-proxy，大大提升了大规模场景下的服务性能，还将容器网络的虚拟网卡对升级为内核新增的 Netkit，从而使得容器网络的性能也达到了几乎跟主机网络相同的性能。伴随着一系列网络、观测、安全、多云等特性的推出，可以说，Cilium 已经从一个单一的 CNI 网络插件进化为一个全能的容器网络解决方案，并朝着成为 Kubernetes 网络唯一的堆栈迈进。

在监控领域，Netflix 在解决嘈杂邻居问题（Noisy Neighbor）时，开源了专用于 eBPF 程序监控和性能优化的 bpftop 项目，提供运行中 eBPF 程序的动态实时视图，并展示每个 eBPF 程序的平均执行时间、每秒事件数和估计的总 CPU 百分比。借助 bpftop，开源社区可以快速发现 eBPF 程序运行过程中的性能问题，并为性能优化提供基准数据。而 Grafana 开源的 Beyla 项目则基于 eBPF 对应用程序进行自动打桩，无需对应用程序代码或配置进行任何修改就可以捕获 RED 指标（速率 - 错误 - 持续时间）以及 Linux HTTP/S 和 gRPC 服务的跟踪度量。

在安全领域，eBPF 基金会发布了 eBPF 安全威胁模型，采用威胁建模方法，从攻击者角度概述了 eBPF 的安全问题和防御措施，并为使用或打算采用基于 eBPF 的企业提供安全指导。报告还特别提供了一些实用的安全建议，值得每个人在实践中采纳，这包括：

最小权限原则：仅授予 eBPF 程序必要的权限。
供应链安全：确保 eBPF 工具和库的安全性和完整性。
定期更新：确保内核和 eBPF 工具使用最新的安全补丁。
监控与日志记录：建立完善的监控和日志记录系统，以检测和应对安全事件。
威胁建模：定期进行威胁建模练习，以识别潜在漏洞和风险。
禁用非特权 eBPF：默认应禁用非特权 eBPF 以减少攻击面。

随着大模型的普及和 AI 时代的到来，eBPF 在 GPU 和 DPU 基础设施中的价值也日益凸显。GPU 和 DPU 价格昂贵，因此所有人都希望能够最大化利用它们的处理能力，而 eBPF 能够以最小的性能开销提供详细的性能分析数据。比如，Meta 和 Deepflow 就利用 eBPF 捕获 PyTorch、CUDA、RDMA 等相关的性能事件，分析系统中的性能问题，从而帮助优化昂贵的 GPU 资源使用。

通过这些进展你可以发现，eBPF 正从单一工具演变为云原生架构中的核心基础设施，而它在 AI 基础设施上的扩展，更说明 eBPF 在新的技术浪潮中扮演着越来越重要的角色。

小结

今天，我带你回顾了 eBPF 在 2024 年的发展历程。过去一年，Linux 内核持续增强了 eBPF 的功能特性，从 6.7 到 6.12 版本引入了一系列重要更新，包括异常处理支持、可编程网络设备 Netkit、Arena 共享内存、Token 权限委托、工作队列和 KPROBE 会话支持，以及可扩展调度器等。这些新特性大大提升了 eBPF 的安全性、性能和灵活性。与此同时，配套的开发库 libbpf 和命令行工具 bpftool 也都集成了这些新功能。

2024 年，eBPF 生态系统呈现出蓬勃发展的态势。在网络领域，Cilium 从单一的 CNI 插件进化为全能的容器网络解决方案；在监控领域，Netflix 开源了 bpftop 项目用于 eBPF 程序监控，Grafana 发布了 Beyla 实现应用程序自动打桩；在安全领域，eBPF 基金会发布了安全威胁模型和最佳实践指南。

特别值得注意的是，随着 AI 时代的到来，eBPF 在 GPU 和 DPU 基础设施中的价值日益凸显，eBPF 也是捕获 GPU 和 AI 应用的性能指标进而优化昂贵 GPU 成本的一大利器。可以说，eBPF 已经从单一工具演变为云原生架构中的核心基础设施。

今天这一讲就到这里了。在 2025 年，我们专栏将继续关注 eBPF 的发展，为大家带来更多的 eBPF 相关的内容。下一次的动态更新预计会在4月份。如果你有对我们课程未来内容的建议，欢迎在评论区提出来，期待你与我一起完善和构建一个最贴近实践的 eBPF 知识体系。

思考题

在这一讲的最后，我想邀请你来聊一聊：在过去的一年中，你是否关注或使用了 eBPF 技术？如果有，你觉得 eBPF 在哪些方面对你的工作或项目产生了帮助？或者，你对 eBPF 的未来发展有什么样的期望？

欢迎在留言区和我讨论，也欢迎把这节课分享给你的同事、朋友。让我们一起在实战中演练，在交流中进步。