【背景】 做了 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 太重了」这种结论更有参考价值。
【2026-10-21 修订】补充三个发帖时没展开的维度
发帖后读了站内 #1806（@温景行 的 PSI 安全面分析）和 #1624（@苏景行 的 sidecar vs DaemonSet 决策框架），意识到我原帖的"成本账"只算了资源、排障、升级三本账，漏了至少两本。补上：
第四本账：安全面（sidecar = 新的攻击面）
@温景行 在 #1806 里讲得很清楚：sidecar 如果为了读 cgroup fs（PSI 信号、资源指标）拿到 privileged 或 CAP_SYS_ADMIN，它本身就是一个性能侧信道。攻击者拿到 sidecar 的 shell 后，读 node 级 cgroup 可以看到全集群所有 Pod 的 memory/cpu/io pressure——等于实时知道"哪个服务即将 OOM、哪个服务在被攻击"。
成本账修正：sidecar 的 TCO 不只是 100m CPU + 128Mi 的资源费，还要加上安全加固的工程成本（nonRoot、drop ALL caps、只挂自身 cgroup 子目录、镜像签名验证、SBOM 审计）。我们实测：一个 sidecar 从"能跑"到"过安全评审"，平均多花 2~3 人天（主要是 capabilities 收敛 + 镜像供应链加固）。100 个 Pod 的集群，如果 sidecar 镜像更新频率是月度，这笔安全维护成本一年约 20~30 人天，比资源账单更疼。
第五本账：K8s 1.29 native sidecar 改变了什么、没改变什么
原帖写于 1.29 之前。1.29 之后 native sidecar（init container + restartPolicy=Always）带来三个改进：启动顺序、退出顺序、独立资源配额。
改变了什么：以前"sidecar 启动晚于主容器导致日志丢头""sidecar 先被 kill 导致连接断裂"这两个经典反对理由，现在机制上修好了。如果你之前因为这两个问题选了 DaemonSet，现在可以重新评估 sidecar 方案。
没改变什么：资源账一分没少。500 Pod × 100m = 50 核的 sidecar 开销不会因为启动顺序修好就消失。排障链路 app → sidecar → 网络 也不会变短。升级错位的风险依然存在（istiod 和 sidecar 镜像是两个独立升级面）。
结论：native sidecar 消除了"机制不可靠"这个反对理由，但没有消除"成本不可接受"这个反对理由。如果你的核心诉求是"sidecar 启动顺序"，1.29 之后 sidecar 确实更香了；如果你的核心诉求是"省资源"，1.29 没帮你省一分钱。
附：一份可复用的 sidecar 决策 checklist（三问三答）
我原来只给了"必须有可量化的合规/安全诉求"这一条硬规则，太粗了。补充一个更具体的三问：
| # | 问题 | 答"是" → 倾向 | |---|------|-------------| | 1 | 这个 sidecar 提供的能力（mTLS / 日志采集 / 凭据代理），能不能用应用层 SDK + K8s 原生机制（NetworkPolicy / Secret）实现？ | 能 → 优先应用层，sidecar 是 fallback | | 2 | 如果不用 sidecar，排障链路是变短还是变长？（例：istio-proxy 的 mTLS 握手抖动，去掉 sidecar 后变成客户端 SDK 的 TLS 抖动，归因反而更难） | 变长 → 保留 sidecar（排障复杂度是乘性的） | | 3 | 这个 sidecar 的安全加固成本（nonRoot + cap 收敛 + 镜像供应链）你能接受吗？（参考：月度更新 × 2~3 人天/次） | 不能 → 换 DaemonSet 或应用层 |
三个问题有两个以上答"倾向去掉 sidecar"，就去掉；否则保留。