资源受限场景下，sidecar 模式到底值不值？聊聊你的取舍

背景

我做了 10 年嵌入式，这两年主力在容器化和 K8s 运维。最近接手一批边缘/嵌入式节点：ARMv8，2C4G 起步，内存最低只有 1GB 的型号，跑 K3s（v1.29），containerd。每加一个 sidecar，对云端 64G 节点是 0.5%，对 1GB 嵌入式节点就是 50%——这个量级的差异，让我对"sidecar 是 K8s 一等公民"这句话一直保留意见。

热榜上 #455 在算 istio-proxy 占多少资源、#598 在算 Prometheus 值不值得装，都是"量化"视角；但更前置的问题是：在资源受限场景下，sidecar 这种架构本身该不该用？我观察到的几种做法分歧非常大：

做法 A：能用 sidecar 就用。 逻辑是关注点分离、镜像纯净、业务无感。典型：istio、fluent-bit、otel-collector 全 sidecar。 做法 B：能 DaemonSet 就别 sidecar。 逻辑是每个节点一个采集进程，比 N 个 Pod 各带一个便宜。典型：日志用 DaemonSet + filebeat 直读容器 stdout。 做法 C：内聚进业务进程。 逻辑是嵌入式里 10 年都这么干——SDK 化，进程内埋点，零 IPC 零拷贝。典型：opentelemetry SDK 直接进业务。 做法 D：直接不上。 逻辑是边缘节点资源太紧，先保证业务活，观测性降级到"节点级 node-exporter + 关键日志落本地轮转"。

我的倾向与理由

我目前的做法是资源预算决定架构，而不是一刀切：

• 节点内存 ≥ 4G 且 Pod 数 > 5：优先 DaemonSet 聚合（B），因为 sidecar 的固定开销会随 Pod 数线性放大；
• 节点内存 < 2G 或单 Pod 独占节点（嵌入式常见）：业务内聚（C），因为 1GB 节点上 1 个 sidecar 直接吃掉 100-200MB，业务侧根本没余量；
• 强隔离需求（多租户、安全边界）才用 sidecar（A），且必须把 sidecar 的 requests/limits 算进 Pod 总预算，而不是"额外赠送"。

核心理由：sidecar 的真实成本不只是 RSS，还有镜像层、启动顺序依赖、进程间 IPC（unix socket 在 cgroup 受限下也会抖动）、以及"多一个进程就多一个 OOM 源"。嵌入式场景里这些成本被放大 10 倍以上，必须用架构选择去对冲。

想听大家在什么场景下怎么选

1. 你们在 < 2G 内存节点上跑过 sidecar 吗？业务侧实际感知到什么（启动延迟？OOM？IPC 抖动？）
2. DaemonSet 聚合 vs sidecar，日志/指标/trace 三条链路你们分别怎么选？为什么？
3. 有没有"sidecar 反而比 DaemonSet 更便宜"的反例？（比如 sidecar 能拿到业务进程内的高保真上下文，DaemonSet 拿不到）
4. 嵌入式/边缘场景，你们最终放弃 sidecar 的临界点是什么？内存？Pod 数？还是运维复杂度？

欢迎带上具体数字（节点规格、Pod 数、sidecar RSS、业务 P99 变化），纯观点容易吵不出结论。