【背景】 做了 10 年容器化与 K8s 运维，最近两年明显感觉到一个趋势：三年前我们上 Istio 时，「服务发现、mTLS、灰度、可观测」几乎是刚需；而现在原生 K8s 1.30+ 的 Gateway API、Service 内部流量策略、native sidecar 容器、加上 Cilium/Capstan 这类 eBPF 数据面，把当年 sidecar 解决的 70% 问题都覆盖了。我手上一个 40+ 服务、K8s 1.29 自建集群的团队，上个月刚把一条灰度链路从 Istio VirtualService 迁到了「Gateway API + 应用层权重」，省掉了两个 sidecar 容器，单 Pod 内存降了 200MB+。
【常见分歧 / 几种做法】
- 派「全上 Istio」：统一流量治理、mTLS 自动加密、全链路 tracing 开箱即用，团队不用各自造轮子；代价是每个 Pod 多 1 个 Envoy，CPU/内存/连接数都翻倍，故障域也多了「istiod 挂 = 全集群流量策略失效」。
- 派「只上 Cilium + 原生 K8s」：eBPF 做 L3/L4、原生做服务发现，L7 策略交给应用（Spring Cloud / Go gateway），省掉 sidecar，运维面小；代价是 L7 灰度、熔断、限流散落在各语言 SDK，一致性靠纪律。
- 派「混合」：核心链路用网格，边缘和批处理用原生；代价是两套心智模型、两套监控、两套 oncall runbook，新人上手成本最高。
【我的倾向与理由】 我倾向「派 3，但默认从派 2 起步」。理由三点：
- 落地成本：sidecar 的隐性成本不在文档里——Envoy 内存基线 ~150MB、启动慢 1-2s、istiod 升级窗口、CNI 与 Istio 版本耦合、sidecar 与业务容器日志/探针互相干扰，这些都要算进 TCO。
- 收益边界：网格真正不可替代的收益只有「团队不写 L7 策略」这一条，如果你的团队 < 15 人、服务 < 30、语言 < 3 种，应用层做 L7 策略的边际成本其实低于运维一个 istiod。
- 可回退性：从原生起步，等规模上来再上网格，迁移成本远低于「上完网格发现用不上再拆」。
【想听大家在什么场景下怎么选】
- 你的服务规模（数量 / 语言数 / 团队人数）到多少时，你才觉得「L7 策略散落在应用里」开始疼？
- 你们有没有「上完 Istio 又拆掉」或「拆完又装回来」的经历？触发条件是什么？
- eBPF 数据面（Cilium / 其他）在你们生产里跑到什么成熟度了？敢不敢把它当「唯一数据面」？
- mTLS 这一条，有没有团队是「靠网格才有」的合规刚需？
- 灰度发布：你更信「网关层权重」还是「应用层路由」？各踩过什么坑？
先抛砖，想听听不同规模、不同技术栈下的取舍路径。
0赞
0收藏
0楼层