背景
我管过一个 600+ Pod 的 K8s 1.28 集群（云厂商 + 自建混合），服务间通信走 mTLS + 全链路 trace，方案是 istio 1.21 + Envoy sidecar 注入。去年 Q4 做容量审计时发现一个扎心数据：
- sidecar 平均吃掉每 Pod 350MB 内存（Envoy 基线 220MB + 启动缓冲），按 600 Pod 算就是 ~210GB 的纯"税"，占整个集群 1.8TB 内存的 11.6%；
- 冷启动时 sidecar 比主容器慢 8~12s，
istioctl proxy-status里经常能看到SYNCED但实际Warming还在跑，readiness 已经放流量了——mTLS 握手没完成就接请求，前 10 秒偶发 502； - 升级 istio 时 Pilot 推新 CDS/EDS，Envoy 热重启窗口里 P99 从 8ms 抖到 220ms，持续 2~3s，一年踩了 4 次。
去年 10 月我们在两个非核心服务（合计 80 Pod）试点 Cilium 2.15 + Tetragon，把 mTLS、L7 policy、trace 注入全部迁到 eBPF 层：
- 内存税消失（eBPF 程序在 kernel 里跑，不占 Pod RSS）；
- 冷启动快 5s（没有 sidecar 容器启动环节）；
- 升级 Cilium 用
ciliumpod滚动替换，业务 Pod 不重启，P99 抖动窗口从 2s 缩到 200ms 以内； - 但代价是：L7 观测能力比 Envoy 弱一档——没有完整的 HTTP body 抓包、W3C trace context 注入要自己写 eBPF 程序、
istioctl pc endpoint这类排障命令没了，得换成cilium monitor+bpftrace。
常见分歧 / 几种做法
社区里大概能听到四种声音：
A. Sidecar 派：隔离干净（业务崩了 sidecar 还活着）、生态成熟（Envoy 的 filter 生态、gRPC/WebSocket 支持完整）、可观测性最强、团队不用懂内核。"eBBF 再快也是内核态，排障复杂度是指数级的。"
B. Ambient / 共享 mesh 派：istio 1.22 的 Ambient 模式（waypoint + ztunnel 共享到节点）就是官方答案，"sidecar 太重、全 eBPF 太激进，Ambient 是中间态"。
C. 全 eBPF 派：Cilium / Tetragon / Pixie 已经把 mTLS、L4/L7 policy、trace 全做进去了，"sidecar 是 2018 年的方案，2026 年还在用就是技术债"。
D. 务实派：核心链路（金融、交易）用 sidecar 保可观测性，非核心服务（内部工具、批处理）用 eBPF，"按 SLA 分级"。
我的倾向与理由
我站 D，但带一个硬约束：核心链路如果切到 eBPF，必须先在内部做一轮 L7 观测能力的"等价性验收"——具体包括：
- trace 完整性：W3C traceparent / baggage 在 HTTP/2、gRPC streaming 场景下 100% 透传（我们踩过的坑：Envoy 默认注入
x-request-id，eBPF 方案里这个 header 得自己写 kprobe 补）； - 故障注入：Chaos 场景下能精确断连 / 注入延迟 / 篡改 header（eBPF 的
sockmap能做，但比 Envoy 的fault_injectionfilter 弱）； - 降级路径：eBPF 程序 panic / 内核升级后不兼容时，必须有自动回落到 sidecar 的通道——这是 eBPF 方案最大的"单点"，内核态出 bug 你没法 hotfix；
- 团队 skill：排障链路从
istioctl切到bpftrace+cilium monitor，至少 2 个 oncall 能独立写 eBPF 程序。
理由：sidecar 的成本是"显性的"（内存、启动时间、升级窗口），eBPF 的成本是"隐性的"（内核态排障难度、内核版本耦合、L7 能力缺口）。显性成本可以算，隐性成本只有踩坑才知道。2024 年我劝大家"先试点再迁移"，2026 年我劝大家"核心链路先证明 eBPF 的 L7 能力等价，再谈迁移"。
想听大家在什么场景下怎么选
- 你们现在 sidecar 占比多少？纯 istio / 部分 Ambient / 全 eBPF / 混合？
- 内存税你们算过吗？按 Pod 数 × sidecar RSS 算出来的"集群税"，占你们总预算多少？
- 核心链路切 eBPF 的话，L7 观测的等价性验收你们怎么做的？有没有具体的 checklist？
- 内核版本：你们是 5.10 / 5.15 / 6.x？eBPF 特性（BPF_MAP_TYPE_ARENA、ring buffer、sockmap）在不同内核上的成熟度差多少？
- 降级路径：eBPF 程序挂了 / 内核升级不兼容，你们有没有"自动回落到 sidecar"的机制？还是直接接受"内核态故障 = 全集群故障"？
- 团队 skill：你们 oncall 里有几个人能独立写 eBPF 程序？这是不是你们卡住 eBPF 迁移的最大瓶颈？
抛砖引玉，想听不同立场的人把"什么场景下选什么"讲清楚。