# Sidecarless 之后：eBPF + AI，服务网格的下一站


服务网格走过了两个阶段。第一个阶段是 Sidecar——每个 Pod 挂一个 Envoy，接管流量，上报指标。做得漂亮，但代价不小。第二个阶段是 Sidecarless——Istio Ambient 把 L4 治理下沉到 ztunnel，Cilium 用 eBPF 替代 kube-proxy，试图把 Sidecar 的尾巴砍掉。

但一个问题一直没变：**可观测性数据越来越大，人能消化的没变多。**

---

## Sidecar 的账，还没算完

Sidecar 模式被诟病最多的是资源开销。每个 Pod 跑一个 Envoy 代理，CPU 和内存线性增长。Ambient 和 Cilium 的回应是：把数据面逻辑尽可能压到内核态，消除每 Pod 代理的开销。

这解决了**计算成本**的问题。但没解决**认知成本**的问题。

一个中等规模的服务网格集群，每秒钟产生的追踪和指标数据量可以轻松超过人类运维的读取速度。就算节点上没有 Sidecar 了，数据量依然在。你用 Grafana 盯几个面板还行，但要在几千条 trace 里找到一根异常链路——你做不到，eBPF 也不行。

---

## eBPF 改变的不是数据量，是数据的深度

eBPF 的杀手级能力不是"快"，是它能看到以前看不到的东西。

Sidecar 代理只能看到 L7 的请求和响应。eBPF 能直接挂载到内核函数——系统调用、网络栈、文件 I/O、进程调度。它不仅知道"这个请求延迟 200ms"，还知道这 200ms 里有多少花在 CPU 等待上、有多少卡在磁盘 I/O 上、有多少是因为内核调度把进程踢出去了。

这些信息 Sidecar 永远拿不到，因为代理跑在用户态，看不到内核态在干什么。eBPF 把可观测性的天花板从"应用层"推到了"系统层"。

但也带来了一个新问题：**数据的维度翻了不止一倍。**

以前你看的是 request latency、error rate、throughput。现在你还要看 syscall distribution、kernel stack trace、CPU runqueue latency、page cache hit ratio——每个维度都可能藏着一个性能异常的根因，但人根本不可能同时盯这么多维度。

---

## AI 不是替代可观测，是帮你读可观测

这正是大模型能接手的部分。

传统 APM 用阈值告警——延迟超过 500ms 就报警。阈值的问题是：你提前不知道正常值是多少。凌晨三点的 CPU 飙 20% 可能是定时任务，上午十点飙 15% 可能是翻车前兆。阈值猜不到，人能猜，但人一天不会看二十四小时面板。

大模型能。把 eBPF 采集的内核级数据流——系统调用分布、内核栈采样、TCP 重传率、调度延迟——喂给大模型，让它做两件事：

1. **异常模式发现。** 不靠固定阈值。大模型在某段时间序列上训练出"正常"的统计分布，偏离就标记。eBPF 数据维度多，AI 的强项恰好是多维模式的归纳。

2. **根因推理。** 这是传统 APM 完全做不到的。报警告诉你"延迟涨了"，AI 能告诉你"因为某 Pod 的 cgroup 被 throttle 了——看，这 30 秒 CPU quota 用尽，对应那段时间的请求全在等调度。"这种跨层的因果链：L7 延迟异常 → L4 TCP 重传升高 → L1 CPU 调度饥饿——只有 eBPF 能同时抓到这三层数据，只有 AI 能把它们串成一条线。

---

## 从 Sidecarless 到 Operatorless

如果你接受"AI 能读 eBPF 数据"这个前提，接下来的推演是自然的：AI 不仅能诊断，还能决策。

一个自治循环大概是这样的：

```
eBPF 采集：系统调用、网络栈、调度延迟
       ↓
大模型分析：异常模式发现 + 根因推理
       ↓
策略决策：限流？切换上游？回滚版本？
       ↓
执行：通过 eBPF 或 Envoy xDS 下发策略
       ↓
eBPF 验证：策略生效？指标恢复正常？
       ↓
反馈回大模型，持续学习
```

Cilium 已经在用 eBPF 做 L3/L4 的策略执行了。Istio Ambient 的 ztunnel 也是类似的方向。但如果把"决策"从控制面抽出来交给大模型，就变成了——你不再需要运维手动设置限流阈值、不再需要人工判断什么时候切流量、不再需要凌晨三点爬起来盯着面板等第二个告警。

**从 Sidecarless（没有 Sidecar）到 Operatorless（不需要人值班）。** 这个跳跃比 Ambient 到 Sidecar 更大。

---

## 现实：路还没修好

说实话，现在还到不了这一步。几个硬问题摆着：

**eBPF 的探针还不稳定。** 内核版本差异、BTF 兼容性、CO-RE 的覆盖范围——这些在实验室里能跑，生产环境一堆边缘 case。挂载一个 kprobe 导致内核 panic 不是没发生过。

**大模型的实时性不够。** eBPF 数据流是毫秒级的，大模型推理是秒级的。中间需要一层流式聚合和摘要，不然 AI 还没读完最新数据，故障已经扩散了。

**决策的可解释性。** 让 AI 直接改网络策略是危险的。至少需要一层人在回路——AI 推荐，人审批，再执行。这个审批窗口可能成为瓶颈。

但这些是工程问题，不是原理问题。方向已经清晰了——数据往下沉（eBPF），决策往上升（AI），人从操作者变成审批者。

---

## 为什么值得做

回到服务网格本身。Istio 做了七年，核心架构没怎么变——控制面 Istiod 下发配置，数据面 Envoy 执行策略。Ambient 把 L4 下沉了，但你和服务网格的交互方式没变：写 YAML，看面板，调阈值。

eBPF + AI 有可能改变这个范式。你不再写限流规则——你告诉 AI"这个服务要保证 99.9% 的 SLO"，AI 自己调参数。你不再盯着 Grafana——AI 把异常提炼成一句话："订单服务延迟升高，根因是支付网关连接池耗尽，建议扩容支付网关。"

这和你当年推服务网格时做的事是同一个方向：**把人的重复决策变成自动化的系统决策。** 只不过当时的工具是 Sidecar 和 Istiod，现在的工具是 eBPF 和 LLM。

内核在变，模型在变，方向没变。