eBPF 云原生观测实战：零侵入的可观测性方案

一句话结论：eBPF 是云原生时代"可观测性"的杀手锏。它让你不用改一行应用代码，就能看到系统全貌。

背景

eBPF（Extended Berkeley Packet Filter）是 Linux 内核的"沙箱程序"：

• 在内核空间运行，安全可控
• 监听网络 / 系统调用 / 性能事件
• 零侵入（不用修改应用）
• 高性能（JIT 编译）

到 2026 年，eBPF 已经从"网络工具"演变成"云原生基础设施"。

4 个核心能力

1. 网络可观测性

传统方式：tcpdump / iptables 日志 / Wireshark
eBPF 方式：Cilium Hubble 自动捕获所有网络流量

应用 → Pod → Service → 外部
       ↓
    eBPF 拦截
       ↓
   Hubble UI（可视化）

2. 性能分析

传统方式：perf / strace / systemtap（侵入式）
eBPF 方式：Parca / Pixie（持续采样）

3. 安全审计

传统方式：auditd / SELinux（配置复杂）
eBPF 方式：Falco / Tetragon（运行时检测）

4. 服务网格

传统方式：Envoy sidecar（资源开销 50MB+）
eBPF 方式：Cilium（内核级别，< 5MB）

实战：部署 Cilium + Hubble

Step 1：安装 Cilium

# 用 Helm 安装 Cilium
helm repo add cilium https://helm.cilium.io
helm install cilium cilium/cilium \
  --namespace kube-system \
  --set hubble.enabled=true \
  --set hubble.relay.enabled=true \
  --set hubble.ui.enabled=true

Step 2：启用 Hubble UI

# 端口转发
kubectl port-forward -n kube-system svc/hubble-ui 12000:80
# 访问 http://localhost:12000

Step 3：观察服务间流量

# 查看所有 namespace 的流量
hubble observe --all

# 过滤 HTTP 流量
hubble observe --verdict DROPPED -f

# 实时查看某个 Pod 的流量
hubble observe pod/default/my-app -f

输出示例：

TIMESTAMP             SOURCE                    DESTINATION
May  7 12:34:56.123   default/order-service     default/payment-service
                      TCP                       TCP
                      HTTP/1.1 POST /charge     FORWARDED
                      latency: 45ms

Step 4：网络策略

# Cilium Network Policy（替代 Kubernetes NetworkPolicy）
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-allow
spec:
  endpointSelector:
    matchLabels:
      app: api
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP

实战：使用 Pixie 调试应用

安装 Pixie

# K8s 集群
helm install pixi pixie-operator/pixie-operator --namespace pl \
  --set deployKey=<your-key>

newpx deploy --namespace pl

常用查询

-- 查询 1：HTTP 错误率
px.Display >> 'px/http'
| where resp_status >= 500
| summarize count() by service
| view table

-- 查询 2：慢请求 Top 10
px.Display >> 'px/http'
| where latency_ms > 1000
| sort latency_ms desc
| limit 10
| view table

-- 查询 3：数据库查询性能
px.Display >> 'px/db'
| where service == 'order-service'
| summarize avg(latency_ms), count() by query
| view table

实时 profiling

-- 持续 30 秒 CPU 火焰图
px.CPUProfile('order-service', '30s')

实战：用 Falco 做安全审计

安装

helm install falco falcosecurity/falco \
  --namespace falco \
  --set falco.json_output=true \
  --set falco.http_output.enabled=true

检测规则示例

# 检测异常 shell 启动
- rule: Terminal shell in container
  desc: Alert if a shell is spawned in a container
  condition: >
    spawned_process and container and
    proc.name in (shell_binaries)
  output: >
    Shell spawned in container
    (user=%user.name command=%proc.cmdline container=%container.name)
  priority: WARNING

# 检测敏感文件访问
- rule: Read sensitive file
  desc: Alert if /etc/shadow is read
  condition: open_read and fd.name = /etc/shadow
  output: Sensitive file read
  priority: CRITICAL

5 个常见坑

坑 1：内核版本不兼容

# 检查内核版本
uname -r
# 需要 >= 4.19

# 检查 eBPF 支持
cat /proc/sys/kernel/unprivileged_bpf_disabled

坑 2：资源占用过高

eBPF 程序本身很轻量（KB 级）
但调试工具（Pixie / Hubble）可能占 100MB+ 内存
✅ 生产环境禁用 debug 模式

坑 3：内核版本与工具不匹配

# Cilium 1.16 要求 Linux 5.4+
# 旧集群需要升级内核或选旧版本

坑 4：网络策略过严

# ❌ 默认 deny 全部 → 调试难
# ✅ 先 allowlist 全部 → 再逐步限制

坑 5：日志太多

Falco 默认规则多 → 日志爆炸
✅ 用 macros 自定义规则集
✅ 配置过滤器（namespace / pod 标签）

何时用 eBPF

✅ 适合

• 云原生 / K8s 集群
• 微服务架构
• 需要细粒度可观测性
• 性能敏感场景

❌ 不适合

• 传统单体应用
• 旧内核（< 4.19）
• 团队不熟悉 Linux 内核

与传统方案对比

维度	传统	eBPF
侵入性	高（需改代码）	零
性能开销	5-20%	< 1%
部署复杂度	中	中
数据粒度	应用层	系统层 + 应用层
学习曲线	平缓	较陡

我的看法

eBPF 是云原生可观测性的未来：

1. 零侵入：不用改应用代码
2. 高性能：内核级执行
3. 生态成熟：Cilium / Falco / Pixie / Parca 都生产可用

对独立开发者的意义：

• 自建服务网格（Cilium 比 Istio 简单 10 倍）
• 自建可观测性（Pixie + Grafana）
• 调试生产环境问题（不用 ssh 到服务器）

未来值得关注：

• eBPF for Windows（跨平台）
• eBPF + AI（智能检测异常）
• eBPF for 安全（运行时防护）

参考

• Cilium 官方文档
• Pixie 查询参考
• Falco 规则
• eBPF Summit 2026

---

本文示例基于 Cilium 1.16 + Pixie 0.7 + Falco 0.41，2026 年 5 月最新版本。