零仪表化可观测性：eBPF如何取代Sidecar舰队
Engineering Team
67%的Kubernetes团队已切换到eBPF可观测性
根据CNCF 2026年度调查，67%的Kubernetes团队现在至少使用一个可观测性支柱（指标、追踪或日志）的eBPF工具——较2024年的29%和2025年的41%大幅增长。这种转变不再是渐进的，而是一场洪流。
原因很简单：传统的基于sidecar的可观测性（Envoy代理、OpenTelemetry Collector sidecar、Datadog代理）消耗大量资源，为每个请求增加延迟，并且需要代码更改或容器修改来进行仪表化。eBPF从内核完成所有这些——无需任何应用更改。
什么是eBPF以及为什么重要
eBPF（extended Berkeley Packet Filter）是一种允许沙箱程序在Linux内核中运行的技术，无需更改内核源代码或加载内核模块。最初设计用于网络包过滤，eBPF已发展为通用的内核可编程框架。
工作原理
- 编写一个小程序——用C或Rust（或使用高级框架）
- 附加到内核钩子点——系统调用、网络事件、追踪点、函数入口/出口
- 内核的eBPF验证器检查程序安全性（无无限循环、无越界访问、有界执行）
- JIT编译器将eBPF字节码转译为原生机器指令
- 程序执行在钩子点以接近原生的性能运行
对于可观测性，这意味着您可以拦截每个HTTP请求、DNS查询、TCP连接、文件系统操作和进程执行——无需修改任何应用代码，无需注入sidecar，无需重启pod。
// 简化的eBPF程序追踪HTTP请求
SEC("kprobe/tcp_v4_connect")
int trace_connect(struct pt_regs *ctx) {
struct sock *sk = (struct sock *)PT_REGS_PARM1(ctx);
u32 pid = bpf_get_current_pid_tgid() >> 32;
u16 dport = sk->__sk_common.skc_dport;
u32 daddr = sk->__sk_common.skc_daddr;
struct event_t event = {
.pid = pid,
.dport = ntohs(dport),
.daddr = daddr,
.timestamp = bpf_ktime_get_ns(),
};
bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU,
&event, sizeof(event));
return 0;
}
为什么对可观测性重要
传统可观测性需要仪表化——向应用添加代码、库或sidecar容器。这种方法有三个根本问题：
- 资源开销——每个sidecar消耗CPU和内存。在500个pod的集群中使用Envoy sidecar，sidecar本身可能消耗集群总资源的30-40%。
- 覆盖盲区——您只能观察到您仪表化的内容。第三方二进制文件、内核级事件和网络基础设施仍然是盲点。
- 维护负担——每种语言、框架和运行时都需要自己的仪表化库。
eBPF解决了这三个问题：在内核中运行（零应用开销），看到内核看到的一切（无盲区），且不受应用语言或框架限制。
2026年eBPF可观测性技术栈
生态系统已经成熟为一组经过实战检验的工具：
Cilium + Hubble：网络可观测性
Cilium是Kubernetes的事实标准CNI（容器网络接口）。Hubble是Cilium的可观测性组件，提供：
- L3/L4流量可见性——pod之间的每个TCP/UDP连接
- L7协议解析——HTTP、gRPC、Kafka、DNS和PostgreSQL，无需应用更改
- 网络策略审计——实时查看哪些策略允许或拒绝流量
- 服务依赖映射——基于观察到的流量模式自动生成服务图
Pixie：应用性能监控
Pixie（CNCF沙箱项目）使用eBPF提供零仪表化APM：
- 自动协议追踪——HTTP/1.1、HTTP/2、gRPC、PostgreSQL、MySQL、Redis、Kafka、DNS
- 持续CPU分析——来自eBPF栈追踪的每个进程火焰图
- 动态日志——无需重新部署即可向运行中的应用添加追踪点
- 完整请求/响应捕获——查看实际的HTTP头、SQL查询、gRPC载荷
Tetragon：运行时安全和审计
Tetragon（由Isovalent/Cilium开发）是基于eBPF的安全可观测性和运行时执行工具：
- 进程执行跟踪——每个exec、fork和exit事件
- 文件访问监控——跟踪读取、写入和权限更改
- 网络连接审计——记录带有进程上下文的每个出站连接
- 安全策略执行——实时阻止可疑活动
Grafana Beyla：自动仪表化
Grafana Beyla是基于eBPF的自动仪表化代理，生成OpenTelemetry兼容的追踪和指标：
- 在内核级检测HTTP、gRPC、SQL和Redis请求
- 发出带有追踪上下文传播的OpenTelemetry span
- 与Grafana Cloud、Tempo、Mimir和任何OpenTelemetry后端集成
性能：重要的数据
以下是来自500个pod生产Kubernetes集群的真实基准测试：
内存使用对比
| 组件 | Sidecar方案 | eBPF方案 | 节省 |
|---|---|---|---|
| Envoy sidecar（500 pod） | 50 GB | 0（Cilium CNI） | 50 GB |
| OTel Collector sidecar（500 pod） | 15 GB | 0（Beyla DaemonSet） | 15 GB |
| Cilium代理（20节点） | N/A | 8 GB | -8 GB |
| Beyla代理（20节点） | N/A | 2 GB | -2 GB |
| 总计 | 75 GB | 12 GB | 降低84% |
CPU开销
| 指标 | Sidecar方案 | eBPF方案 |
|---|---|---|
| 每请求增加延迟 | 1-5ms | <0.1ms |
| 每节点CPU开销 | 8-12% | <1% |
| 尾延迟影响（p99） | +15-30ms | <1ms |
迁移指南：从Sidecar到eBPF
第1阶段：在Sidecar旁边部署eBPF工具（第1-2周）
- 安装Cilium作为CNI
- 部署Hubble进行网络可观测性
- 部署Beyla作为DaemonSet进行自动仪表化追踪
- 并行运行sidecar和eBPF可观测性
第2阶段：验证和调优（第3-4周）
- 验证eBPF工具捕获相同的信号
- 调整Beyla的协议检测
- 设置镜像现有sidecar仪表板的新仪表板
第3阶段：逐步移除Sidecar（第5-8周）
- 从非关键服务开始：移除OTel Collector sidecar
- 监控数据质量回归
- 从不需要高级流量管理的服务中移除Envoy sidecar
第4阶段：完整eBPF技术栈（第9-12周）
- 移除剩余sidecar
- 部署Tetragon进行运行时安全
- 整合基于eBPF信号的告警
- 回收释放的资源
常见问题
eBPF可观测性适用于非Kubernetes工作负载吗？
是的。eBPF在Linux内核级运行，适用于任何工作负载——容器、VM、裸机、systemd服务。
eBPF能替代分布式追踪吗？
对于许多团队，是的。Beyla和Pixie从内核观察生成分布式追踪。但eBPF追踪仅限于请求/响应边界——无法追踪函数内的自定义业务逻辑。
加密流量（TLS）怎么办？
eBPF工具可以通过附加到TLS库函数（如OpenSSL的SSL_read和SSL_write）来追踪TLS流量。
eBPF安全吗？有缺陷的eBPF程序会使内核崩溃吗？
不会。eBPF验证器在加载前检查每个程序。有缺陷的程序将无法加载——永远不会使内核崩溃。
eBPF如何处理高吞吐量服务（100K+请求/秒）？
eBPF通过内核内聚合和采样处理高吞吐量。eBPF程序可以在内核映射中计算直方图和计数器，只发送聚合数据到用户空间。