eBPF 云原生可观测性实战：告别传统埋点，拥抱内核级洞察
传统可观测性靠的是应用层埋点——在你代码里插 `traceSpan`、`metrics.Inc()`，然后等着数据上报。这套东西在微服务少的时候挺好使，但上了 Kubernetes 几百个 Pod 之后，问题就来了：**盲区太多、性能损耗、升级改动大**。
前言
传统可观测性靠的是应用层埋点——在你代码里插 traceSpan、metrics.Inc()，然后等着数据上报。这套东西在微服务少的时候挺好使，但上了 Kubernetes 几百个 Pod 之后，问题就来了：盲区太多、性能损耗、升级改动大。
eBPF 换了个思路：不让应用主动上报，让内核帮你看。不需要改一行代码，就能拿到网络延迟、文件系统 I/O、内存分配、系统调用分布——全部在 kernel space 完成，对应用零侵入。
今天聊一下 eBPF 在云原生环境里的实际用法，包括如何用 Cilium 替换 kube-proxy、怎么用 eBPF 程序做网络流量分析、以及生产级部署的坑。
---
1. 为什么传统埋点会瓶颈
1.1 注入式 APM 的代价
传统方案（Jaeger、Datadog APM、OpenTelemetry）的工作原理是：
1. SDK 注入到你的应用进程
2. 每个请求路过 SDK 时记录 span
3. 数据通过 HTTP/gRPC 发送到一个 collector
4. Collector 处理后存到后端
问题在哪？每一个 span 都有开销。在你高频调用的路径上，这个开销会变成真实延迟。2024 年 AWS 的一个内部测试显示，在 Go 服务里启用完整链路追踪会增加 8-15% 的 P99 延迟。
另外，语言/框架多样性带来碎片化。你 Node.js、Python、Go 各一套 SDK，升级策略完全不同，有的地方漏埋了就是盲区。
1.2 Kubernetes 网络的可观测性真空
在 K8s 里，Pod 间的流量不经过物理网卡，而是走 veth pair → docker0/bridge → iptables/nftables → 路由。这个路径上，传统抓包工具（tcpdump）看不到加密流量，sidecar 模式（如 Istio envoy）注入了额外的 hop，而服务网格的自定义指标覆盖率也无法达到 100%。
---
2. eBPF 工作原理快速入门
2.1 什么是 eBPF
eBPF（extended Berkeley Packet Filter）是 Linux kernel 里的一个沙箱虚拟机。你写一段程序，kernel 验证它安全（不会死循环、不会越界访问），然后把它 attach 到某个内核 hook 上执行。
关键特性：
- **内核沙箱验证**：不安全代码直接拒绝，不会上线
- **内核直接执行**：不需要进用户态，少一次 context switch
- **可动态 attach/detach**：不需要重启进程，不需要改代码
2.2 程序类型和 Hook 点
2.3 简单示例：一个统计 TCP 连接数的程序
用 BCC（BPF Compiler Collection）写一个内核模块：
`python
#!/usr/bin/env python3
from bcc import BPF
program = """
#include
#include
// 用 hash map 统计每个 src_ip 的连接数
BPF_HASH(conn_count, u32);
int count_tcp_accept(struct pt_regs *ctx) {
u32 sip = bpf_get_current_uid_gid() & 0xFFFF; // 简化示例
conn_count.increment(sip);
return 0;
}
"""
b = BPF(text=program)
b.attach_uprobe(name="tcp_v4_do_rcv", fn_name="count_tcp_accept")
`
这个例子说明了 eBPF 程序的核心模式：读取内核状态 + 写入 map + 返回结果。
---
3. Cilium：用 eBPF 重写 K8s 网络
3.1 传统 kube-proxy 的问题
kube-proxy 用 iptables 做 Service 负载均衡。当集群规模大了，iptables 的规则数量线性增长，查询复杂度从 O(1) 退化到 O(n)。5000 个 Pod 时，iptables 规则数轻松破 10 万条，Service 查找成为性能瓶颈。
3.2 Cilium 的方案
Cilium 把 iptables 全部替换成 eBPF 程序，attach 到 socket 层和 TC（traffic control）层。
核心优势：
- **天然支持 Kubernetes NetworkPolicy**：eBPF 在 socket 层直接做过滤，不需要额外的 sidecar
- **Service 负载均衡 O(1)**：用 BPF hash map 查找，规则数增加不影响查找速度
- **host routing**：绕过 iptables，直接在网卡层做转发，延迟降低 20-40%
部署 Cilium：
`yaml
# cilium-install.yaml（Helm values 片段）
operator:
replicas: 1
bpf:
loadBalancerMode: embedded # 使用 eBPF 做 embedded L4 LB
ipv4:
enabled: true
kubeProxyReplacement: strict # 完全替换 kube-proxy，不混合使用
`
`bash
helm install cilium cilium/cilium \
--namespace kube-system \
-f cilium-install.yaml
# 验证 eBPF 程序已加载
cilium status --verbose
`
3.3 Hubble：eBPF 原生的可观测性
Cilium 自带 Hubble，这是一个基于 eBPF 的全链路追踪系统，不需要任何应用埋点：
`bash
# 启用 Hubble UI
cilium hubble enable --ui
# 命令行查看实时流量
hubble observe --to-namespace default
`
输出示例：
`
Dec 8 14:32:11.438: 10.0.0.23:4040 -> 10.0.0.45:8080 L4 TCP CONNECTION ESTABLISHED
dst_endpoint_id=495 src_label=k8s:app=api
Dec 8 14:32:11.512: 10.0.0.23:4040 -> 10.0.0.45:8080 L4 TCP CONNECTION DROPPED (Policy denied)
dst_endpoint_id=495 src_label=k8s:app=api
`
每个流量事件直接来自内核的 socket hook，不需要任何应用配合。
---
4. 生产级部署：坑与最佳实践
4.1 内核版本要求
eBPF 功能随内核版本不断演进。以下是需要注意的版本门槛：
生产建议：使用 Ubuntu 22.04 LTS（5.15 内核）或 RHEL 9，内核版本不要太旧。
4.2 eBPF map 内存上限
eBPF map 是内核里的共享存储，默认内存上限较小。大量 Pod 场景下会耗尽：
`bash
# 查看当前限制
sysctl kernel.bpf.max_entries
sysctl kernel.bpf.max_maps
# 调大（需要 root）
sysctl -w kernel.bpf.max_entries=1000000
sysctl -w kernel.bpf.max_maps=4096
`
可以在 /etc/sysctl.conf 里持久化：
`
kernel.bpf.max_entries=1000000
kernel.bpf.max_maps=4096
`
4.3 安全边界：CAP_BPF vs CAP_SYS_ADMIN
生产环境不要给 eBPF 程序加载权限 CAP_SYS_ADMIN，用 CAP_BPF + CAP_NET_ADMIN 足够：
`yaml
securityContext:
capabilities:
add:
- BPF
- NET_ADMIN
drop:
- ALL
`
Cilium 自动处理这个，不需要手动配置。
4.4 可视化工具链
生产可用的观测工具：
- **Grafana + eBPF Exporter**：用 ebpf_exporter 把 eBPF 指标暴露给 Prometheus
- **Parca**：开源的持续 profiling，基于 eBPF 采样 CPU、内存
- **Pixie**：K8s 原生的可观测平台，不需要埋点，自动接入 Cilium
Pixie 接入示例：
`bash
# 一行安装
px deploy
# 查看实时 HTTP 延迟分布（不需要任何配置）
px run-script p.ssl_latency -n default
`
---
5. 结论：eBPF 让观测成为基础设施
eBPF 带来的核心改变是：可观测性从应用责任变成了基础设施责任。你不需要说服每个团队在每个服务里埋点，基础设施团队部署 Cilium/ Hubble 之后，所有 Pod 的网络流量、Service 访问延迟、安全事件就全部可见了。
这条路的代价是：需要内核 5.x+，需要团队理解 eBPF 的基本概念，工具链还在快速演进（相比之下，传统 APM 生态更成熟）。
如果你在管理大规模 K8s 集群，对网络延迟敏感，对安全合规有要求，eBPF 可观测性是值得投入的方向。起点很低：Cilium 装上，Hubble 启用，你就已经有全链路观测了。
---
相关阅读
- Cilium 官方文档：https://docs.cilium.io
- BCC 工具链：https://github.com/iovisor/bcc
- eBPF 峰会录像：https://ebpf.io/summit