Sidecar 到底是必需品还是历史包袱？聊聊你团队里还在跑的 sidecar

背景

我在 3 个不同团队里都见过 sidecar：Istio 的 envoy、log 采集的 filebeat/fluent-bit、mesh 里的 mTLS、还有"为了绕开 K8s 原生能力"硬塞进来的 proxy。同一个集群里，有的 sidecar 跑了三年没人动过，有的从第一天起就在偷偷吃 CPU 和内存，直到某次 CFS 节流把主容器 P99 拖飞才被翻出来。

我最近一次复盘：一个 Java 订单服务，主容器 2C4G，envoy sidecar 实际常驻 300MB 内存 + 0.3C，加上 log sidecar 200MB —— 两个 sidecar 加起来吃掉主容器 15% 的资源预算，但业务侧从未在容量规划里把它们算进去。这不是 bug，是我们默认 sidecar 是"透明的、免费的"。

社区里的几种流派，我观察到至少四种

• 派 A「sidecar 是云原生标配」：mTLS、流量治理、日志、tracing 全靠 sidecar 注入，业务代码零侵入。代表：Istio + FluentBit + Jaeger 三件套。优点是业务团队不用懂网络，缺点是 sidecar 升级、排障、容量规划全是隐性成本。
• 派 B「sidecar 是历史包袱，能去掉就去掉」：日志直接写 stdout 让 daemonset 收；mTLS 用 cert-manager + 应用层自己管；tracing 走 SDK。代表：Envoy 被 Go 原生 net/http 替代，mesh 拆掉。优点是资源干净、链路短，缺点是安全与可观测性下放到业务代码，团队能力参差时容易翻车。
• 派 C「sidecar 该有，但要算账」：每个 sidecar 必须申报 CPU/MEM 预算、纳入 HPA 决策、纳入容量规划；没有预算的 sidecar 不允许进 prod。这是我现在最倾向的做法，下面展开。
• 派 D「按场景分」：数据面 sidecar（envoy）保留，控制面 sidecar（log、tracing）迁走；或者反过来。

我的倾向与理由

我倾向派 C + 派 D 的组合：sidecar 不是"要不要"的问题，是"哪些 sidecar 值得、哪些不值得"的问题。判断标准我一般看三条：

1. 是否改变主容器的网络/进程模型。envoy 改的是网络路径，故障域扩大；filebeat 只读文件，故障域基本隔离。前者必须算账，后者可以放宽。
2. 是否有原生替代且替代成本可接受。K8s 1.25+ 的 stdout 采集、cert-manager 的证书分发、eBPF 的 tracing，都在蚕食 sidecar 的存在理由；但 Istio 的 mTLS 目前还没有"零侵入 + 零 sidecar"的成熟替代，硬拆会付出安全债。
3. 升级与回滚是否独立。sidecar 和主容器耦合越紧，越不能独立升级 —— 这时它就不是 sidecar，是"半主容器"，必须按主容器的标准管理。

落到操作上，我团队的三条硬规矩：

• 每个 sidecar 在 Helm chart 里必须有独立的 resources.requests/limits，且计入主 Pod 的总预算，不允许"sidecar 不设 limit 靠主容器兜底"。
• sidecar 的镜像 tag 必须 pin 死，禁止 latest；升级走独立的发布流水线，不与主容器同批发布。
• 季度做一次"sidecar 审计"：列出集群里所有非业务容器，逐个回答"它为什么在这里、谁负责、能不能被原生能力替代"。答不上来的，下季度摘掉。

想听大家聊的

1. 你们团队现在 prod 里跑着几个 sidecar？都是谁？哪个最"安静"、哪个最"吵"？
2. 有没有把 sidecar 拆掉之后反而更糟的案例？（我见过拆掉 envoy 之后 mTLS 自己写，结果证书轮换出过事故）
3. 派 C 的"预算制"你们觉得能落地吗？还是会被"sidecar 不算业务资源"这条潜规则绕过？
4. 未来 1–2 年，你们预期 sidecar 这个角色会被 eBPF / 内核能力 / 原生 K8s 特性吃掉多少？哪些会留到下一代？

欢迎贴你们的 sidecar 清单和预算数字，数字比观点更有用。