K8s 集群日志无限堆积把节点磁盘打到 90%：按服务做日志磁盘预算和自动清理，你们是怎么落地的？

【背景】 我做了 5 年运维，目前维护一个 20 节点（32C128G，Kubernetes 1.27 + containerd 1.6）的集群，上面跑着约 200 个无状态微服务。日志链路是：容器 stdout → fluent-bit DaemonSet → Kafka → Elasticsearch，fluent-bit 同时把日志落一份在节点本地磁盘 /var/log/pods 下（主要是给排障时兜底用）。

【现象】 最近两个月，「节点磁盘使用率 >85%」的告警每周响 2~3 次，基本都是凌晨 2~4 点。每次登上去看，都是 /var/log/pods 下的日志文件堆了 40~60G，其中 80% 的体积来自 5 个左右"话痨"服务（某个支付网关、两个报表服务、一个定时任务、一个网关 access log）。其他 195 个服务的日志加起来不到 5G。磁盘一满，fluent-bit 写 Kafka 的 buffer 也会受影响，偶尔出现日志丢失。

【已尝试的排查与结果】

1. 给 fluent-bit 配了 file rotation（100MB × 10 个文件），但只解决了 fluent-bit 自身 buffer 的磁盘占用，解决不了容器 stdout 落盘的部分；
2. 在节点上写了个 cron 脚本，每天凌晨清理 7 天前的日志文件，能缓解，但"话痨"服务在高峰期 6 小时就能再写 30G，脚本赶不上；
3. 想过给每个服务设 ulimit 或者 cgroup 限制日志写入速率，但担心影响业务写入路径，没敢动；
4. 和 SRE 讨论过直接砍掉本地兜底日志（反正 ES 里有），但业务方坚持要"万一 ES 挂了能翻本地日志"。

【期望得到的答案形态】 想听听大家生产环境里的真实做法，具体一点更好：

• 你们是怎么给"每个服务"定日志磁盘预算的？是按 namespace、按服务、还是按节点总量一刀切？
• 自动清理是放在节点 cron、fluent-bit filter、还是 sidecar 里做的？清理策略是什么（按时间、按大小、按保留条数）？
• 有没有人做过"按服务区分日志保留时长"的方案（话痨服务保留 2 天、普通服务保留 7 天）？怎么实现的？
• 本地兜底日志和 ES 双写的矛盾，你们最后是怎么平衡的？

欢迎贴出你们的配置片段、cron 脚本或者 fluent-bit filter 配置，越具体越好，谢谢！