扩展的伯克利数据包过滤器（eBPF）是IT运维工程师的梦想：通过允许ITOps团队部署高效的程序，这些程序可以深度运行在操作系统内部，eBPF承诺简化IT环境的监控、观察和安全性管理。
这引出了一个问题：如果eBPF如此强大，为什么它还没有在各个地方普及？毕竟，eBPF技术已经存在多年，并且在IT社区中获得了广泛关注（包括在本网站）。那么，为什么IT专业人士仍然在沿用旧的方式，而不是转向eBPF呢？
我认为，原因涉及多个因素。
你能用eBPF做什么？
在探讨eBPF为什么只有限度采用之前，让我们简要了解一下eBPF是什么，它能做什么。
eBPF是内建于Linux内核中的一个框架，能够编写并执行自定义程序。这些程序可以从它们运行的系统中收集几乎任何类型的数据。这使得eBPF成为收集安全监控、系统监控和性能管理信息的强大工具。
此外，由于eBPF程序在一个沙箱环境中运行，它们比传统的内核级代码执行方法（如插入内核模块）更安全、更稳定。你也不需要修改内核代码或重新编译内核来运行eBPF程序；你可以将它们动态加载并执行到运行中的系统中，这使得eBPF非常灵活。
eBPF起源于2010年代中期，作为伯克利数据包过滤器（BPF）的改进版本，这是一项已有数十年历史的技术，用于在类Unix系统上捕获和过滤网络数据包。
eBPF的有限采用
自约十年前eBPF面世以来，它确实取得了一定的采用。例如，Cilium开源项目使用eBPF在云原生环境中实现可观察性和安全性。一些商业监控和可观察性工具现在也支持eBPF来收集数据。
然而，总体来看，eBPF的普及速度似乎并不像人们预期的那样快，考虑到其潜在的革命性特性。例如，在可观察性领域，OpenTelemetry—一个本身不原生使用eBPF的框架—仍然是热门话题。（OpenTelemetry提供了一个eBPF收集器，可以使两者协同工作，但该收集器过去一年没有得到太多开发活动。）在安全性领域，eBPF也尚未彻底改变现状。
eBPF的现状
有几个因素解释了为什么eBPF并未如预期那样成为革命性技术。
1.eBPF代码的复杂性
编写eBPF程序需要特定的专业知识。这不是任何一个具备基本Python知识的人能轻松完成的。因此，实际实施eBPF对于大多数组织来说是一项繁重的工作。
值得注意的是，你不一定需要编写eBPF代码来使用eBPF。你可以选择使用一些利用eBPF的软件工具（例如Cilium），这些工具背后使用了eBPF，但不需要用户编写大量的eBPF代码。但如果你选择这种方式，你将无法自定义eBPF以满足你的需求。
除非eBPF编程变得更简单，或者更多人能够编写eBPF程序，否则我认为这些程序的复杂性是eBPF进一步普及的一个主要障碍。
2.eBPF中的内核特定依赖
几乎每次Linux内核发布新版本时，eBPF框架也会带来一个新版本。这种快速的变化意味着，某个版本的Linux上可以运行的eBPF程序，可能在另一个版本上无法运行——即使这两个版本使用的是相同的Linux发行版。
从这个角度来看，eBPF对IT团队需要支持的软件环境变化非常敏感，这使得它很难成为处理关键任务的可观察性和安全性工作流的可靠选择。
3.缺乏Windows支持
至少目前，eBPF只在Linux上工作。理论上，Windows版本的eBPF正在开发中，但它已经开发了多年，仍不清楚它何时、甚至是否会真正投入实际使用。
这一限制意味着eBPF不能作为一个平台无关的解决方案，这使得它对那些在Linux以外环境运行工作负载的公司吸引力较小。
4.eBPF有成熟的竞争者
导致eBPF采用受限的一个最终因素是，已经存在许多优秀的工具，并且它们并不依赖于eBPF。从这个角度来看，eBPF提供了一种新的手段来实现同样的目标——而鉴于传统的手段对于许多组织来说已经足够有效，很多人可能认为没有理由转向eBPF。
当然，eBPF提供了更高的效率等优势，这可能会降低基础设施成本，因为eBPF程序可能比传统工具消耗更少的CPU和内存资源。但鉴于大多数人对于不需要修复的东西持保留态度，不能怪IT团队如果他们现有的非eBPF解决方案已经足够满足他们的需求，不愿采用eBPF。
我预计eBPF的采用会继续增长。但这一过程将是缓慢的，因为eBPF的主要用户群体相对较小。它由那些专注于Linux的IT团队组成，这些团队习惯于编写eBPF程序的复杂任务，并且看到了eBPF相比传统工具的优势，愿意用它来代替现有工具。而其他人将在可预见的未来继续使用他们已经在使用的工具，无论eBPF多么令人惊叹。
