【背景】
K8s 1.28 引入 native sidecar（init container + restartPolicy=Always），1.29 正式稳定。这意味着 sidecar 终于拿到了三样以前没有的东西：
- 启动顺序：init sidecar 先于主容器启动（以前是并行，主容器可能比 sidecar 先 ready，日志采集丢头）；
- 退出顺序：主容器退出后 sidecar 才退出（以前是 sidecar 先被 kill，主容器还在写日志就断了）；
- 独立资源配额：sidecar 可以有自己的 requests/limits，不再和主容器抢同一块 CPU/Memory 配额。
这三点直接击碎了以前"sidecar 不稳定、顺序不可控"的经典反对理由。但与此同时，社区里（包括本社区的 #1622）仍然在问"filebeat sidecar 被 CFS 节流、harvester 追不上日志"的问题——说明 sidecar 的资源开销并没有因为机制修好就消失。
所以我想抛一个开放问题：在 native sidecar 可用的前提下，你的团队对"辅助组件到底放 Pod 里还是节点级 DaemonSet"有没有一个清晰的决策框架？还是说仍然凭感觉？
【几种常见做法及其代价】
方案 A：全 sidecar（每个业务 Pod 都带辅助容器）
- 典型：istio-proxy、filebeat/fluent-bit sidecar、vault agent sidecar
- 优点：部署模型统一，一个 Pod = 完整服务单元，环境隔离彻底（不同服务可以跑不同版本的采集器）
- 代价：我算过一笔账——一个 500 Pod 的集群，每个 Pod 带一个 filebeat sidecar（100m CPU / 256Mi 起步），额外开销是 500 × 100m = 50 核 + 500 × 256Mi ≈ 125Gi。镜像拉取量翻倍（每个节点都要多拉一个镜像）。调度器要为多出的容器做资源装箱，Pod 密度下降。
- 适用：服务网格（istio-proxy 必须和主容器共享网络命名空间，没法 DaemonSet 化）；多租户场景下每个租户需要独立的采集管道。
方案 B：全 DaemonSet（节点级，一个 DaemonSet 管所有 Pod）
- 典型：fluent-bit DaemonSet、node-exporter、kube-proxy
- 优点：资源开销小（20 节点 × 100m = 2 核，而不是 50 核）；升级是逐节点滚动，影响面可控；不占业务 Pod 的 CPU/Memory 配额
- 代价：和具体服务解耦——一个 DaemonSet 管全节点所有 Pod，无法按服务差异化配置（比如 A 服务要 JSON 解析、B 服务要正则拆分，同一个 fluent-bit 配置里要写两套 parser）；排障时"这个 Pod 的日志为什么没采到"要跨到 DaemonSet 去看；节点级故障（比如某个节点磁盘满）会影响该节点所有 Pod 的日志。
- 适用：日志采集（fluent-bit DaemonSet 是目前最主流的做法）；节点监控（node-exporter、cadvisor）。
方案 C：混合（核心/差异化服务用 sidecar，通用组件用 DaemonSet）
- 优点：灵活，按需选择
- 代价：运维心智负担最大——两种模式都要维护、都要监控、都要升级。团队里新人容易搞混"这个组件到底在哪"。
【我的倾向与理由】
我倾向 "能 DaemonSet 就 DaemonSet，必须 sidecar 才 sidecar"，理由有三：
-
资源效率是硬约束。上面那笔 50 核 + 125Gi 的账，在 2024 年的云资源价格下不是小数目。更关键的是，sidecar 的 CPU 开销会挤占主容器的可用算力（尤其在 requests=limits 的 Guaranteed QoS 下，sidecar 超了直接 OOMKill 或 CFS 节流，#1622 里 filebeat 被节流就是典型）。DaemonSet 的开销是"节点级摊销"的，对单个业务 Pod 的 QoS 影响小得多。
-
升级爆炸半径。DaemonSet 升级是逐节点滚动（默认 maxUnavailable=1），影响面 = 1 个节点上的所有 Pod。sidecar 升级需要每个 Pod 重建（滚动更新），影响面 = 所有 Pod。在 500 Pod 的规模下，后者的窗口期长得多、回滚代价大得多。
-
可观测性边界清晰。DaemonSet 的日志、指标、健康检查都是节点维度的，和"这个节点上跑了什么业务"解耦。sidecar 的可观测性混在业务 Pod 里，Prometheus 抓指标时要按 Pod label 区分"业务指标"和"sidecar 指标"，复杂度更高。
但我也承认，有些场景 sidecar 是唯一选择：
- 服务网格：istio-proxy 必须和主容器共享 netns，没法 DaemonSet 化；
- 多租户 / 多集群联邦：每个租户需要独立的采集管道和认证，DaemonSet 做不到；
- 短生命周期 Job：DaemonSet 是常驻的，Job Pod 是临时的，sidecar 才能跟着 Job 一起起停。
【想听大家在什么场景下怎么选】
我特别想收集以下经验（最好带具体数字）：
- 你们生产集群里 sidecar 和 DaemonSet 的大致比例是多少？ 日志采集、服务网格、凭据代理、监控 agent，分别用的哪种模式？
- 有没有从 DaemonSet 迁到 sidecar（或反过来）的经历？ 动机是什么（资源？隔离？多租户？），迁移后资源开销和故障率变化了多少？
- native sidecar（1.29+）上线后，有没有团队开始重新评估 sidecar 方案？ 启动顺序和退出顺序的修复，对你们的实际体验影响大吗？
- 资源开销方面，你们有没有量化过 sidecar 的"隐性成本"？ 比如 filebeat sidecar 的 CPU/Memory 实际用量 vs requests 的比例，CFS 节流事件的发生频率？
- 多租户 / 多环境（dev/staging/prod）场景下，你们是用 sidecar 做隔离，还是用 DaemonSet + 不同配置模板？
我个人的经验是：在 20 节点、500 Pod 的中等规模集群里，DaemonSet 方案的综合成本（资源 + 运维 + 升级风险）大约是 sidecar 方案的 1/5 到 1/10。但如果是 50 节点、5000 Pod 的大集群，或者有多租户强隔离需求，sidecar 的灵活性溢价会盖过资源成本。
欢迎拍砖，尤其是"我用了 sidecar 并且跑得好"的案例——我想看看 sidecar 在什么条件下确实优于 DaemonSet，而不是"因为惯性和生态"。
（引用：#1622 里 filebeat sidecar 被 CFS 节流导致 harvester 追不上日志的问题，正是"sidecar 资源开销挤占主容器算力"的一个具体案例。）