首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >eBPF 到底是什么?为什么 2025 年还在爆火?

eBPF 到底是什么?为什么 2025 年还在爆火?

作者头像
不吃草的牛德
发布于 2026-04-23 12:40:02
发布于 2026-04-23 12:40:02
1K0
举报
文章被收录于专栏:RustRust

想象一下:你家门口装了个“智能门卫”,它不换锁、不改门,却能实时拦截可疑快递、记录所有进出人员、甚至自动升级规则——这一切都不影响门的正常开关。

这就是 eBPF 在 Linux 内核里干的事。

2025 年已经过去,2026 年开年,eBPF 依然是云原生、安全、观测性圈子里最热的关键词之一。Cilium 发布了 1.19 版、AI 模型的可观测性离不开它、国产操作系统大面积适配……它为什么这么火?今天用 3 个生活比喻 + 几张对比图,帮零基础的你彻底搞懂。

一、传统内核开发 vs eBPF

传统方式想在内核加功能,只有两条路:

  • • 写内核模块(.ko 文件)→ 直接插进内核,功能最强,但一出 bug 容易蓝屏/死机,整个机器跟着遭殃。
  • • 修改内核源码重新编译 → 周期长、维护地狱、几乎没人敢在生产这么干。

eBPF 来了以后,情况变成了:

项目

传统内核模块

eBPF 程序

运行位置

内核态,直接执行

内核态,但被严格沙箱 + 验证器校验

加载方式

insmod,随时崩溃系统

通过 syscall 加载,加载失败不影响内核

安全性

极高风险(有权限=可为所欲为)

验证器保证“不会死循环、不会越界、不会崩溃内核”

更新方式

卸载重载模块,服务中断

原子替换程序,几乎零中断

开发语言

C(内核子集)

C / Rust / Go(通过 libbpf 等)

生产友好度

极低(云厂商基本禁了)

极高(云原生标配)

代表玩家

老网卡驱动、某些安全软件

Cilium、Falco、Pixie、DeepFlow

一句话:eBPF 把内核从“一次性水泥建筑”变成了“可插拔的乐高积木”。

二、eBPF 诞生简史:从 BPF 到 eBPF 的三次进化

eBPF 不是 2025 年突然冒出来的新玩具,它其实已经 30+ 岁了。

  1. 1. 1992 年:经典 BPF(cBPF) 最初是为了 tcpdump 诞生的“包过滤器”。 目标很简单:在内核快速判断“这个包我要不要抓”,避免把所有网络包都拷贝到用户态(太浪费 CPU)。 这就是最早的“内核里跑小程序”。
  2. 2. 2014 年:扩展 BPF(eBPF)诞生 Linux 3.15/3.18 时代,Alexei Starovoitov 大神把 BPF 指令集大幅扩展:
    • • 可以访问更多内核数据结构
    • • 可以挂在更多 hook 点(网络、跟踪、socket、kprobe/uprobe 等)
    • • 引入了验证器(verifier)——这成了 eBPF 的“安全灵魂” 从此 eBPF 不再只是包过滤器,而是通用内核可编程框架。
  3. 3. 2019–2025 年:第三次进化——生产级成熟
    • • CO-RE(Compile Once – Run Everywhere):一次编译,到处运行,不再依赖特定内核版本
    • • BTF(BPF Type Format):让 eBPF 程序能读懂内核数据结构,像“带类型的 JSON”
    • • Ring Buffer、BPF iterators、BPF token 等新特性
    • • Cilium、Falco、Katran、Pixie 等明星项目大规模落地
    • • 甚至 Windows、Android 也开始支持 eBPF

结果:2025 年底,eBPF 已经从“实验性黑科技”变成了“云厂商必须支持的基础设施”。

三、2025 年还在爆火的 4 大原因(数据说话)

很多人以为 eBPF 是 2020–2023 年的风口,2025 年应该凉了吧?恰恰相反,2025–2026 年它反而进入“爆发第二阶段”。

  1. 1. Cilium 真正成熟(1.17 → 1.19 时代) Cilium 项目在 2025 年发布了 1.17、1.18、1.19 多个大版本,全面支持 Gateway API、Cluster Network Policy、eBPF 驱动的负载均衡与安全。 全球大量公司把 Istio/Linkerd 替换成了 Cilium + eBPF,延迟下降 40–60%,CPU 节省 30%以上。 它不再是“未来技术”,而是“现在生产标配”。
  2. 2. Kubernetes 生态越来越离不开 eBPF 虽然 Kubernetes 本身还没“强制要求 eBPF”,但 2025 年大量发行版和云厂商的最佳实践已经把 eBPF 网络(Cilium)、运行时安全(Falco)、深度观测(OpenTelemetry + eBPF auto-instrumentation)列为推荐/默认选项。 尤其是 AI 训练/推理集群,传统观测工具根本看不清 GPU/网络/调度细节,eBPF 成了事实标准。
  3. 3. AI 可观测性 / LLM Observability 的刚需 2025 年 AI 应用爆炸,LLM、AI Agent、训练集群的能耗、延迟、成本、幻觉问题都需要内核级可见性。 eBPF 提供了零侵扰、全栈观测能力(网络、系统调用、加密流量解密后行为、power management 等),成为 Datadog、New Relic、Grafana、DeepFlow 等厂商的底层引擎。 一句话:没有 eBPF,AI 可观测性就是盲人摸象。
  4. 4. 国产操作系统 + 信创全面适配 麒麟、统信 UOS、龙芯、飞腾等国产平台在 2025 年大规模验证和适配 eBPF 工具链(eCapture、DeepFlow 等)。 信创项目对“可控、安全、不依赖外企内核模块”的需求,让 eBPF 这种“在内核里跑用户态代码”的方式成了首选。 很多金融、政务、能源客户 2025 年开始强制要求“eBPF 技术栈”。

四、eBPF vs DTrace / SystemTap / 传统 Kernel Module 终极对比表

很多人会问:以前不是有 DTrace、SystemTap 吗?为啥非要 eBPF?

特性

DTrace (Solaris/ macOS/FreeBSD)

SystemTap (Linux)

传统 Kernel Module

eBPF (现代 Linux)

跨平台

差(基本 Solaris/macOS)

仅 Linux

仅 Linux

Linux + Windows + …

安全验证

无(root 即一切)

有限

无

强验证器(最严格)

生产环境友好

中等

较差(编译依赖内核头)

极差

极好(原子热更新)

性能开销

低

中等

最低(但风险最高)

极低

社区活跃度(2026)

下降

稳定偏低

下降

爆炸增长

典型用户

Apple、老 Solaris 用户

部分企业

老网卡驱动

Cilium、Falco、字节、阿里、腾讯

一句话总结

“Unix 的天才之作,但时代变了”

“Linux 的半吊子 DTrace”

“核弹级威力,无限风险”

“内核里的 JavaScript”

五、一句话总结:eBPF = 「内核里的 JavaScript」

  • • JavaScript 让浏览器从静态页面变成了可编程平台
  • • eBPF 让 Linux 内核从静态系统变成了可编程平台

都是“在沙箱里安全运行用户代码”,都能热更新、跨版本兼容、社区生态爆炸。

不同的是:JavaScript 改变了前端,eBPF 正在改变整个后端基础设施。

下一期我们直接上手:3 分钟跑通第一个 eBPF Hello World,零基础也能玩!

你对 eBPF 最感兴趣的是哪个方向?安全?观测?网络?还是 AI?评论区告诉我,下篇优先写你关心的!

(完)

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2026-03-03,如有侵权请联系 cloudcommunity@tencent.com 删除
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档