过去几年,eBPF在云上的角色悄然改变。它最早被当作内核可观测的显微镜,用于追踪系统调用、网络连接与函数耗时;如今,它正被云计算厂商放到安全执行与网络数据面的关键路径上,成为云平台默认启用的内核级运行时。
从可选插件到默认开启的内核能力
eBPF允许在不修改内核源码、不加载内核模块的前提下,把经过验证的小程序挂载到内核的挂钩点上。早期落地集中在可观测领域,Cilium的Hubble、Pixie、Parca等项目用它在生产环境做无侵入追踪。随着Linux内核把BPF LSM、struct_ops、XDP等接口逐步纳入主线,云厂商开始把它从可选插件升级为基础能力。多家公有云已在节点上默认加载eBPF程序,负责容器网络转发、连接追踪与安全策略执行,用户不必再关心iptables规则膨胀带来的性能衰减。
安全执行成为新战场
安全侧的推进最受关注。传统主机安全依赖内核模块或用户态代理:前者对内核版本敏感且有稳定性风险,后者难以覆盖短生命周期的容器。eBPF提供了另一条路径,在内核的关键决策点挂载程序,实时阻断异常行为。Cilium的Tetragon、Falco的现代驱动都基于这一思路,把运行时策略从事后告警推进到事中拦截。
- 进程与容器维度:按镜像签名、命名空间与安全上下文下发策略,拦截可疑提权与横向移动;
- 网络维度:在XDP层做DDoS清洗与四层负载均衡,替代部分专用硬件设备;
- 数据面维度:以sockmap、TC程序加速服务网格,减少内核协议栈的多次数据拷贝。
云上落地的三道坎
规模化的前提是解决几个工程问题。其一是内核碎片化,不同发行版与内核版本接口不一致,CO-RE与BTF让一次编译、处处运行成为现实,但仍需在持续集成中覆盖多版本验证。其二是多租户权限,BPF程序运行在内核态,一旦被滥用就是最隐蔽的rootkit;内核新引入的BPF令牌与最小权限模型,正把加载、附加、映射访问拆分为细粒度授权。其三是性能与可移植性的权衡,复杂程序在验证器面前容易被拒,需要更克制的指令设计与充分的压测。
与AI算力集群的交叉
新一轮增长来自AI集群。大规模GPU训练对网络时延与带宽极为敏感,基于eBPF的拥塞控制、可编程数据面与GPU侧遥测开始被引入,用于观测集合通信、定位慢节点。相比改造应用,在内核层做观测与调度调整,对训练框架更透明,迁移成本也更低。
可以预见,eBPF在云上的定位会继续上移:从运维工具变成平台的安全与网络底座。真正的竞争不在于谁先把程序挂上去,而在于谁能把权限模型、版本兼容与性能开销管理好,让它在大规模多租户环境下长期稳定运行。