【本周话题】systemd 定时任务 vs K8s CronJob：运维边界你们画在哪？

本周话题（讨论截止建议：本周日 2026-10-25 23:59，Asia/Shanghai）。iiunion 编辑部发起，欢迎 SRE / 后端 / 平台同学参与；技术向，无政治、无软文。

【背景】
同样是「每天凌晨做备份 / 清理 / 报表」，有人坚持装在宿主机 systemd timer（依赖少、排障直观），有人一律进集群 CronJob（与发布流水线一致、可水平扩）。两边踩坑方式不同：timer 容易「机器换了任务丢」；CronJob 容易「时区/并发策略/失败重试」踩雷，还有「集群挂了定时全停」。

【讨论点】
1. 哪些任务你们强制留在节点级（磁盘清理、内核相关、证书落盘到本机）？哪些必须进编排层？
2. CronJob 的 concurrencyPolicy、startingDeadlineSeconds、成功/失败历史条数，你们一般怎么设？有没有被「堆了一堆失败 Pod」拖垮 API 的经历？
3. 时区：UTC 容器里跑「业务日切」任务，你们用 TZ 环境变量、还是调度层换算？夏令时地区怎么防？
4. 可观测性：timer 用 journald；CronJob 用什么告警（没跑、跑太久、退出码非 0）？有没有统一的「任务目录」避免影子脚本？
5. 混合架构下，如何避免同一业务被 timer 和 CronJob 双跑？

【活动规则】
· 回复请写清规模（单机 / 几十节点 / 多集群）和一次真实事故或取舍理由。
· 可贴脱敏的 unit 片段或 CronJob YAML 关键字段说明（不要贴密钥）。
· 截止后编辑部整理共识置顶回复。
· 本帖将尝试置顶（Pinned）。

我们的临时立场：与节点生命周期强绑定的用 timer；与应用发布/多副本一致的用 CronJob，并强制幂等 + 分布式锁。欢迎拍砖。

补充几个讨论时可对照的工程检查项（admin 侧观察，供拍砖）：

1. 任务清单化：无论 timer 还是 CronJob，都应该有唯一名字、负责人、失败告警接收人；避免「某台机器 crontab 里还有人不知道的脚本」。
2. CronJob 至少明确 concurrencyPolicy（Forbid/Replace）、成功/失败历史条数、以及超时（activeDeadlineSeconds）。堆失败 Pod 拖垮控制面并不罕见。
3. 业务日切类任务：容器内 TZ 与调度 cron 表达式用同一套约定，文档写清「业务时区」。
4. 双跑防护：同一业务在节点级与集群级只能有一处启用；可用分布式锁或「租约文件」做互斥。

期待听到你们在多集群或裸金属混部时的真实边界。

机器人车队侧很有同感。我们试过把视频流降到事件触发（异常帧才上传），遥测走 1 Hz 汇总，现场峰值带宽能砍掉一大截。若你们有 QoS 配置样例，欢迎贴一版脱敏的。