适用场景

eBPF 的价值在于「不用改业务代码就能看到内核态发生了什么」。排障时它能把「服务慢」拆成「内核协议栈慢、队列慢、还是对端慢」。但 eBPF 依赖内核版本和权限，落地前先确认内核版本与安全策略，别在生产上随便加载探针。

配置步骤（Cilium Hubble 观测 K8s 流量）

# 1) 安装（示例：helm）
helm repo add cilium https://helm.cilium.io/
helm install cilium cilium/cilium --namespace kube-system \
  --set hubble.relay.enabled=true --set hubble.ui.enabled=true

# 2) 命令行走访访问关系
hubble observe --namespace prod --last 50
hubble observe --namespace prod --to-service web --verdict DROPPED

# 3) 排障：谁在被拒
hubble observe --verdict DROPPED --namespace prod | head -20

# 4) 指标接入 Prometheus
kubectl port-forward -n kube-system svc/hubble-relay 4245:80

关键参数与建议

  • 内核版本：4.19 以上功能较完整，5.x 以上可用较新的 BTF 与 CO-RE 能力
  • 权限：加载探针需要 CAP_BPF/CAP_SYS_ADMIN，生产环境按需授权并记录
  • 观测点选择：TCP 重传、连接建立耗时、socket 队列、文件读写延迟最实用
  • 采样率：高流量场景必须采样或按条件过滤，否则开销明显
  • 数据落地：指标进 Prometheus，明细进日志或对象存储，避免内存爆
  • 安全边界：内核升级或容器运行时升级后要回归验证探针兼容性
  • 与现有工具配合：ebpf 看内核，应用 APM 看代码，两边对齐时间戳

容易踩的坑

  • 网络策略上线后没人看 dropped 流量，业务不通排查一小时
  • Hubble 数据不落盘，重启后历史全丢
  • relay 未做资源限制，节点内存被吃
  • 只看 allow 不看 verdict，忽略策略误伤
  • 用了 overlay 却没注意 MTU，出现碎片与重传
  • 观测面板开了但没接告警，出问题仍靠用户报障

验证与巡检

# 策略误伤定位
hubble observe --verdict DROPPED --namespace prod --last 200 | grep -c DROPPED
kubectl get networkpolicy -A

# MTU 与丢包
kubectl exec -n prod deploy/web -- ip link show eth0
kubectl exec -n prod deploy/web -- ping -M do -s 1400 -c 3 10.96.0.1
  • 巡检：dropped 流量有告警、策略变更留痕、MTU 一致、relay 资源水位正常

小结

eBPF 落地检验：能用一个命令说清某次慢请求的时间都花在哪一段（应用、内核队列、网络、对端），并且开销可控。

> 说明：文中命令为通用写法，不同型号/版本可能略有差异，落地前请对照设备实际版本的官方文档；带外管理与安全设备变更建议先在测试设备验证。