【背景】 做了 5 年云原生，前三年主力推的是 Istio 服务网格，最近一年在几个新项目里开始往「应用内 SDK（Envoy Go SDK / gRPC interceptors / otel SDK）+ 少量 CNI（Cilium）+ 裸 K8s」的方向回退。回来复盘了一下自己过去几年给团队算的成本账，发现一个有点反直觉的结论：「sidecar 是零成本的能力增强」这个叙事，在大多数中小规模团队是不成立的。
几个我反复踩过的坑：
- 资源账：100 个业务 Pod，每 Pod 一个 sidecar，按 istio-proxy 默认 100m/128Mi 起步算，光 mesh 就要吃掉 10 核 + 12.8G，还不算控制面（istiod + galley）的常驻开销。对小团队来说，这笔钱比很多业务 Pod 本身还贵。
- 排障账：sidecar 一旦介入，链路就变成 app → iptables → sidecar → 网络，任何一层的 P99 抖动都要拆三次才能归因；我见过太多「服务 A 调服务 B 偶发超时」最后定位到是 sidecar 的 mTLS 握手或 DNS 解析在抖的案例。
- 升级账：istiod 版本升级、CNI 升级、sidecar 镜像升级，三者节奏不一致时会出现「控制面 1.21 / sidecar 1.20」这种错位，回滚成本极高。
【常见分歧 / 几种做法】 我观察到社区大致分三派：
- All-in 网格派：认为 mTLS + 零信任 + 可观测性 + 流量治理必须下沉到基础设施层，sidecar 是「一次性投入，长期收益」，应用层做这些是重复造轮子。代表场景：金融、政企、强合规。
- All-in 应用层派：认为 sidecar 的隐性成本（资源、排障、升级）远超显性收益，把 mTLS 交给服务发现 + 证书 SDK、把可观测性交给 otel SDK、把限流交给应用网关，K8s 只做调度。代表场景：中小规模、快速迭代、业务侧有强诉求的团队。
- 折中派：核心链路（如支付、风控）保留 sidecar 拿 mTLS 和流量治理，边缘链路（内部工具、批处理）走裸链路；或只保留 Cilium 的 L3/L4 能力（网络策略 + eBPF 指标），把 L7 能力交给应用层。
【我的倾向与理由】 我偏向第三派，但有一条硬规则：sidecar 的存在必须能被「一个具体的、可量化的合规/安全诉求」justify，而不是「架构先进性」。理由：
- 成本是显性的（资源账单），收益是隐性的（安全能力），隐性的东西必须挂在可审计的诉求上，否则 6 个月后没人记得当初为什么上；
- 排障复杂度是乘性的（每多一层就 ×1.5），不是加性的；
- 中小团队的真实痛点是「快速迭代 + 低成本」，不是「架构完美」，把预算花在业务侧的稳定性上 ROI 更高。
但这不是「sidecar 没用了」——如果你们有强 mTLS 诉求、有跨团队协作需要流量治理、有多租户隔离需求，sidecar 依然是最省心的方案。问题在于多数团队不知道自己是不是真的需要，只是「别人都在用所以我们也用」。
【想听大家在什么场景下怎么选】 特别想收集三类真实案例：
- 从「全网格」回退到「应用层 SDK」的团队：你们省了多少资源？排障链路变短了多少？有没有踩到「回退后某个能力丢了」的坑？
- 从「裸链路」升级到「全网格」的团队：你们的触发点是什么（一次安全事件？一次合规审计？）？升级后第一年的 TCO 变化？
- 折中派的边界怎么划：你们用什么标准判断「哪些服务需要 sidecar、哪些不需要」？有没有一份可复用的 checklist？
另外想抛一个更尖锐的问题：如果 2026 年让你从零搭一个新集群，没有历史包袱、没有合规压力，你还会给业务 Pod 挂 sidecar 吗？为什么？
期待看到带数字的回复（资源占用、排障耗时、升级成本），比「我觉得 sidecar 太重了」这种结论更有参考价值。
0赞
0收藏
0楼层