eBPF技术深度盘点：虚拟网络、云观测、FinOps等六大核心应用领域

深入研究eBPF技术应用多年，直到为eBPF 基金会撰写相关论文时，我才清晰地看到哪些领域最能发挥其潜能，或者从中受益最深。

eBPF已超越单一工具范畴，成为重塑云原生基础设施的核心技术。那么，它究竟在哪些领域引发了显著的变革？又有哪些意想不到的应用场景正在崛起？

以下是当前受益于eBPF最为显著的六大类别：

• 最显著的进步 — 虚拟化网络
• 最高的采用者 — 运行时安全
• 最佳性能提升 — 网络安全
• 意料之中的 — 云可观测性
• 意料之外的 — LLM 安全
• 最酷的 — FinOps

（本文核心观点编译自 The 6 biggest eBPF beneficiaries - by Andrew Green）

最显著的进步 — 虚拟化网络

虚拟化网络形式多样，涵盖了软件定义网络、超大规模云网络以及Kubernetes容器网络等。虚拟化带来了灵活性，但也引入了抽象层难以避免的性能开销。

eBPF如何破局？它允许数据包处理、策略执行和路由逻辑直接在内核中运行。这从根本上提升了虚拟化网络的性能与可扩展性，实现了传统软件架构难以企及的效能。想了解此类技术如何在现代基础设施中落地生根？欢迎来云栈社区与广大开发者和运维/DevOps/SRE同行们交流实践心得。

目前，一些最佳的eBPF实践正发生在容器网络接口（CNI）层面：

• Cilium：这款开源CNI几乎与eBPF同义，其设计完全基于eBPF，旨在一站式解决容器的网络、安全与可见性问题。
• Project Calico：作为另一个主流开源CNI，它提供了基于eBPF的可插拔数据平面，专门用于优化Kubernetes的网络与安全。

最佳性能提升 — 网络安全

传统的网络安全设备往往需要数据包绕路。而eBPF改变了游戏规则：数据包检查与过滤直接在每个端点的内核层面完成，并利用Linux流量控制子系统挂载到网络接口的入口与出口点。这相当于构建了一个分布式防火墙，轻松实现微分段。

基于eBPF的网络安全方案支持广泛特性，包括L4/L7有状态过滤、基于信誉的检测、微分段、IP伪装和NAT。这意味着网络安全不再局限于物理或虚拟的“黑盒”，而是成为了操作系统内部一个不可或缺、可编程的层次，能够随工作负载无缝扩展，是零信任架构的理想实践。

实际案例如下：

• Aviatrix：在其Distributed Cloud Firewall产品中集成eBPF，用以分析、观测并执行云环境内及跨云流量的安全策略。
• Cloudflare：凭借基于eBPF的DDoS防护系统，曾成功抵御了一次高达7.3 Tbps的攻击。
• Netfoundry：其独立防火墙应用ZittiFirewall，利用tc-ebpf和XDP技术提供有状态的IPv4/IPv6防火墙功能。

最大的采用者 — 运行时安全

运行时安全旨在为进程或应用执行期间提供保护，典型代表是终端检测与响应（EDR）及其演进版本——下一代扩展检测与响应（XDR）。EDR仅防护终端，而XDR试图将安全能力扩展至云端、网络等更广范围。然而，传统代理方案消耗资源多、管理复杂，且非内核模块方案的可见性与执行力受限于API。

因此，运行时安全领域迅速拥抱了eBPF。通过在内核中安全、高效地运行动态程序，eBPF带来了前所未有的执行与可见性能力，催生出更强大的产品，如云检测与响应（CDR）和应用检测与响应（ADR）。

• Crowdstrike Falcon Data Protection for Cloud：利用eBPF为静态和动态云数据提供运行时保护，实时检测并阻止未授权的数据移动，且对系统性能影响极低。
• Sysdig Falco：这款开源的云原生运行时安全工具，能实时检测并告警异常行为与潜在安全威胁。
• Upwind：其eBPF传感器能够创建预防性策略，自动阻止恶意进程在工作负载中运行。

意料之中的采用者 — 云可观测性

传统的可观测性依赖于代理、Sidecar和SDK，从不同层面采集指标、日志和追踪数据。拼接这些碎片化视角总会带来数据缺口、延迟和额外开销。

eBPF则从根本上消除了这种复杂性——它在内核层面提供统一的视角。无需修改任何代码，就能从内核中获取丰富数据：分布式追踪、服务拓扑、特定协议（如HTTP、gRPC、SQL、Kafka）的使用情况、系统调用、网络事件以及性能数据。

对本地数据中心而言，eBPF甚至能提供硬件级的可观测性，洞察内存访问模式、磁盘I/O和网络接口行为，帮助定位硬件争用与性能瓶颈。在混合云环境中，这一优势更为突出：无论工作负载运行在何处，eBPF都能通过相同的内核钩子提供一致的遥测，消除因混合使用不同供应商监控工具而产生的盲点，最终形成一个统一的、事件驱动的全系统视图。

• Datadog：在构建通用服务监控（USM）时使用eBPF代理，直接从内核网络栈解析HTTP(S)流量。
• New Relic：收购了开源项目Pixie，这是一个Kubernetes原生的集群内可观测性平台，能即时洞察K8s工作负载。
• Odigos：使用eBPF自动生成OpenTelemetry格式的追踪数据，其性能测试显示，基于eBPF的自动插桩比手动插桩代码快20倍以上。

最酷的采用者 — FinOps

如何在不完全依赖云厂商账单的情况下精确计算云成本？eBPF探针提供了新思路。通过实时监控系统调用、负载级别的网络流量和应用行为，eBPF能够厘清云服务的使用方式，并将其与内核事件关联。

eBPF让那些“看不见”的低效之处变得可见。通过观察CPU调度、网络路径和I/O模式，可以精准定位浪费。这种细粒度的数据还能在共享服务或多租户环境中区分不同租户的消耗，从而将成本准确地归因到具体的云服务，如托管数据库、对象存储或出口流量。

• Pelanor：其eBPF Kubernetes传感器可为集群、命名空间、工作负载乃至单个网络端点提供细粒度的成本分配。
• Attribute：将eBPF探针收集的细粒度数据与业务指标关联，以计算成本并提供可执行的云支出洞察。
• Groundcover：利用eBPF追踪所有Kubernetes集群中的资源使用情况，用于资源消耗监控和实时支出跟踪。

出人意料的采用者 — LLM 安全

保护生成式AI应用，特别是那些使用大语言模型（LLM）的应用，对安全架构师而言是一个新挑战。有趣的是，许多旨在解决LLM安全问题的工具，都直接选择了eBPF来追踪应用程序与外部LLM服务之间的交互。

为什么是eBPF？通过在网络层部署，这些解决方案能够无侵入地监控并记录API调用，捕获请求/响应数据、延迟、错误率等关键信息，为AI应用的安全与性能分析提供了全新维度。

• Prompt Security（已被SeninelOne收购）：使用eBPF跟踪应用程序与向量数据库之间的通信，提供对查询模式、响应时间及潜在问题的深度洞察。
• Protect AI（已被Palo Alto Networks收购）：利用eBPF来发现和监控AI应用的使用情况。

---

引用链接

1. The 6 biggest eBPF beneficiaries - by Andrew Green: https://greenabstracts.substack.com/p/the-6-biggest-ebpf-beneficiaries?sort=new
2. eBPF 基金会: http://ebpf.io
3. 基础设施平台的 eBPF: https://www.linuxfoundation.org/hubfs/eBPF/The_State_of_eBPF25_111925.pdf
4. 成功阻止了一次 7.3 Tbps 的攻击: https://blog.cloudflare.com/defending-the-internet-how-cloudflare-blocked-a-monumental-7-3-tbps-ddos/