on-failure:n是唯一能限制重启次数的策略，如on-failure:3表示最多重启3次；always和unless-stopped无上限，易引发雪崩，必须配合healthcheck与资源限制才能有效防故障扩散。
关键在于用 on-failure 策略配合明确的重试上限，避免容器反复崩溃又立即重启，挤占调度资源或掩盖真实故障。
为什么不限制重试次数会出问题
当容器因代码缺陷、配置错误或依赖不可用而持续失败时，若使用 always 或未设限的 on-failure，Docker 会在毫秒级内不断拉起新实例。这会导致：
- 进程表和内存被大量僵尸或半启动容器占用
- 日志刷屏，掩盖首次失败的关键线索
- 健康检查与监控系统被高频“抖动”干扰，误判集群状态
- 在 Kubernetes 中可能触发节点驱逐或 Horizontal Pod Autoscaler 误扩容
设置合理最大重试次数的实操要点
使用 --restart=on-failure:N（N 为整数）是核心手段，但需结合场景判断 N 值：
-
批处理类任务：设为
on-failure:1或on-failure:3。这类容器本就该“执行完即退出”，反复重启无意义，应靠任务编排器（如 Airflow、CronJob）控制重试逻辑 -
短生命周期服务（如数据导入、迁移脚本）：推荐
on-failure:2，覆盖网络瞬断或临时锁冲突等偶发问题 -
长驻服务但强依赖外部组件（如需连特定数据库或配置中心）：可设
on-failure:5，并搭配--restart-max-delay（Docker 24.0+）引入指数退避，例如：docker run -d --restart=on-failure:5 --restart-max-delay=60s nginx
配套必须做的两件事
单设重试次数不够，还需切断失败循环的源头：
-
加健康检查：用
HEALTHCHECK主动探活，让 Docker 在容器“活着但不工作”时也能标记为 unhealthy，避免无效重启。例如：HEALTHCHECK --interval=20s --timeout=3s --retries=2 CMD curl -f http://localhost/ready || exit 1 -
限制资源并观察指标：为容器设置
--memory=512m --cpus=0.5等约束，并用docker stats或kubectl top pod确认是否因 OOM 或 CPU 节流导致退出——这类问题重试再多也无效，必须调优配置或修复应用
