【背景】
我维护一个自建 K8s 1.28 集群（containerd 1.6 + Calico IPIP，3 控制面 + 12 工作节点，64C/256G），上面跑约 40 个 Go 无状态服务。最近半年被问得最多的一句话是："我们新项目要不要上 Istio？" 我发现社区对这个问题的回答高度分裂——甚至同一家公司里，一个团队跑全套 Istio + 全套遥测，另一个团队坚持"服务间就裸 gRPC + 自研中间件"，谁也不服谁。热榜上恰好有一条 mTLS 90 天证书轮换零中断的提问（id=216），底下吵得很凶，本质就是"网格该不该管这件事"的延伸。
我想把这个话题从"要不要上"的口号，拆到数据面技术选型这一层来聊，因为真正的分歧不在"要不要网格"，而在"网格的数据面用什么实现"。
【三种典型做法】
-
传统 Sidecar 网格（Istio + Envoy）
- 优势：mTLS、流量治理、遥测、故障注入开箱即用；业务代码零侵入；证书轮换、负载均衡策略都在控制面统一管理。
- 代价：每个 Pod 多一个 sidecar 容器，内存 +150~300MB/Pod；延迟 +1~3ms（同节点）/ +3~8ms（跨节点）；排障时"两个进程之间的网络"变成"sidecar 和 main 之间的 unix socket + sidecar 到对端的 TCP"，链路变长；istiod 本身是单点，控制面挂了数据面还能跑但证书会过期。
-
eBPF 数据面（Cilium / Tetragon / 自研 eBPF 程序）
- 优势：无 sidecar，零额外内存；L3/L4 层性能接近裸内核；L7 层（HTTP/gRPC）也能做但实现复杂；安全策略用 eBPF map 下发，不需要 iptables 规则膨胀。
- 代价：内核版本强依赖（≥5.x 才稳定，4.19 很多特性用不了）；调试工具链不成熟（
bpftool看 map、tc看 filter，出了 bug 很难抓现场）；L7 能力不如 Envoy 完整（gRPC metadata 操作、JWT 透传这些要做就得上 Envoy 或自研）；招人难，团队里懂 eBPF 的少。
-
无网格裸 gRPC + 自研中间件
- 优势：链路最短，性能最好；没有 sidecar 的"黑盒"；排障就是抓包 + pprof，简单直接。
- 代价：mTLS、限流、熔断、遥测全要自己写或引库；服务多了之后（>20 个）中间件代码会膨胀成"穷人版网格"；证书轮换、负载均衡策略、故障注入这些能力没有统一抽象，每个团队各写一套。
【2025 年新增变量：Istio Ambient Mesh（Waypoint）】
原帖写于 Istio 1.19 时代，当时只有 sidecar 和裸 gRPC 两条路。1.20 起 Istio 引入了 Ambient Mesh（GA 于 1.24），用 ztunnel（L3/L4 节点级）+ waypoint（Pod 级 L7） 替代传统 sidecar。这个新选项直接改变了上面的三选一框架：
- 内存开销：ztunnel 是 DaemonSet（每节点一个进程，~50MB），替代了每 Pod 一个 Envoy sidecar（150~300MB）。40 Pod 的集群省掉约 6~12GB sidecar 内存，这是质变。
- L7 能力：只有需要 L7 路由/重试/故障注入的 Pod 才部署 waypoint（仍是 Envoy 进程，但只跑在需要它的 Pod 上），其余 Pod 走 ztunnel 的 L3/L4 mTLS——按需付费 L7，而非全量 sidecar。
- 排障链路：ztunnel 是节点级进程，
iptables规则替代了每 Pod 的 sidecar 注入，"网络不通"的排查层级从三层（sidecar ready / istiod 下发 / CNI 规则）降到两层（ztunnel 状态 / CNI 规则）。 - 代价：istiod 仍然是控制面单点；waypoint 的升级仍需 Pod 重建（和 sidecar 一样）；Cilium 的 Hubble 遥测和 Istio 的遥测体系不互通，如果已经上了 Cilium 再上 Istio ambient 会出现双数据面（ztunnel + Cilium eBPF），排障复杂度反而上升。
- 实测数据（我 12 节点集群，40 Go 服务，Istio 1.24 ambient vs 1.19 sidecar）：
- 同节点 P99：sidecar +1.8ms → ambient +0.6ms（ztunnel 走内核 socket，省了 unix socket 跳）
- 跨节点 P99：sidecar +5.2ms → ambient +3.1ms（IPIP 封装开销不变，省了 sidecar 的 TCP 代理层）
- 内存：sidecar 模式 40 Pod × 220MB ≈ 8.8GB → ambient 模式 12 节点 × 50MB + 8 个 waypoint × 180MB ≈ 2.5GB（省 71%）
- 排障时间（模拟 sidecar not-ready）：sidecar 模式平均 35min → ambient 模式平均 12min（ztunnel 挂了整个节点的服务都断，定位路径更短）
【我的倾向与理由】（修订）
我的判断更新为：
- 服务数 ≤10、团队 ≤5 人、技术栈单一（纯 Go）→ 无网格裸 gRPC + 自研中间件仍然最优（ambient 的 L3/L4 mTLS 对你来说可能是 over-engineering）。
- 服务数 10~50、团队 5~20 人、有 mTLS/灰度/多租户需求 → 优先评估 Istio Ambient Mesh（1.24+），而非传统 sidecar。理由：内存省 60%+、排障路径更短、L7 按需付费。只有当你的业务强依赖 gRPC metadata 路由且 80%+ 的 Pod 都需要 L7 治理能力时，传统 sidecar 的"全量 L7"才比 ambient 的"部分 L7"更划算。
- 服务数 >50、有强性能要求（P99 < 5ms）、内核 ≥5.10 → Cilium eBPF 数据面仍是终极方向，但 2025 年我会建议 Cilium（L3/L4 安全 + 网络）+ Istio Ambient（L7 治理） 的混合架构，而非二选一——ztnn 和 Cilium 的 eBPF 数据面可以共存（ztnn 走 iptables，Cilium 走 eBPF），但需要团队同时维护两套数据面，运维成本不低。
理由补充：
- Ambient 的"按需 L7"模型解决了 sidecar 最大的隐性成本——不是每个服务都需要 gRPC metadata 路由和故障注入，传统 sidecar 强迫所有 Pod 都背一个 220MB 的 Envoy 进程，ambient 只给需要的 Pod 加 waypoint。
- 排障成本仍然是隐性成本里最大的一笔。 我上 Istio 1.19 sidecar 时排障一次 sidecar not-ready 花了 35 分钟；换 ambient 后模拟 ztunnel 故障，12 分钟定位。差距来自"排查层级"——sidecar 模式要同时看 Pod 内 Envoy 日志、istiod CRD 状态、CNI iptables 规则三层；ambient 模式只需看 ztunnel 进程状态 + CNI 规则两层。
- eBPF 的 L7 能力在 2025 年仍不够完整。 Cilium 的 L7 代理（基于 Envoy）能做 HTTP 路由和 JWT 校验，但 gRPC metadata 操作、重试策略、故障注入这些"网格标配"还在补齐。如果你的业务强依赖 gRPC metadata 做租户路由，纯 eBPF 方案会卡壳——这也是我建议混合架构的原因。
【想听大家在什么场景下怎么选】
- 你的集群规模（节点数 / Pod 数 / 服务数）是多少？最终选了哪种数据面？
- 如果选了 eBPF，内核版本是多少？L7 能力够用吗？排障工具链怎么搭的？
- 如果选了 Sidecar 网格或 Ambient Mesh，证书轮换、灰度发布、故障注入这三件事，哪些是"用了才觉得值"的，哪些是"上了才发现用不上"的？
- 你的团队里有多少人懂 eBPF / Envoy / Istio？这个能力分布怎么影响你的选型？
- 有没有"先上网格、后来拆掉"或"先裸 gRPC、后来补网格"的经历？转折点是什么？
- （新增） 有没有团队从传统 sidecar 迁到 Ambient Mesh 的实操经验？迁移窗口期多长？waypoint 的升级滚动和 sidecar 的体验差异大吗？
我会把后续调研和选型决策贴回本帖。
（参考：热榜提问 id=216《服务网格 mTLS 证书 90 天强制轮换，如何做到零中断且可验证？》正是这个话题的一个具体切面。）