容器重启策略在单节点由Docker守护进程控制，但在集群中被Swarm/K8s编排层策略覆盖；高可用依赖编排系统控制器与健康检查联动实现自愈。
重启策略在单节点上的基础作用
容器重启策略（如 always、on-failure、unless-stopped）是 Docker 守护进程层面的本地行为控制机制。它决定容器退出后是否重启、何时重启、最多重试几次。例如：
– always：只要 Docker daemon 运行，容器停止就立即重启，包括宿主机重启后；
– on-failure:3：仅非零退出码时重启，最多 3 次，避免无限循环；
– unless-stopped：比 always 更“温和”，手动执行 docker stop 后不再自动拉起。
集群编排中重启策略的定位变化
在 docker swarm 或 kubernetes 等集群环境中，单容器的 restart 策略基本失效或被覆盖：
- Docker Swarm 忽略容器级
--restart参数，改用service create --restart-condition（如on-failure或any）统一管理服务任务； - Kubernetes 完全不识别 Docker 的 restart 策略，而是通过 Pod 的
restartPolicy字段控制（仅支持Always、OnFailure、Never），且该策略作用于整个 Pod 生命周期，与底层容器引擎解耦； - Swarm 的
restart-condition和 K8s 的restartPolicy都运行在编排层，能感知节点状态、健康检查结果和调度约束，远超单机守护进程的能力。
真正起效的高可用机制在编排层
集群中的自愈能力依赖的是编排系统自身的控制器逻辑，而非容器重启参数：
- Swarm：Manager 节点通过 Raft 协议维护全局状态，检测到某节点失联或任务失败后，自动在其他健康节点上重新调度新任务；
- Kubernetes：kubelet 上报 Pod 异常，Controller Manager 中的 ReplicaSet/Deployment 控制器发现副本数不足，触发新建 Pod；Liveness 探针失败还会先终止旧 Pod 再重建；
- 两者都依赖 健康检查（healthcheck） 提供更精准的故障信号——比如 HTTP 探针连续失败 3 次，才判定为 unhealthy，进而触发编排层的恢复动作。
生产建议：分层配置，避免策略冲突
在集群环境中，应按层级明确职责：
- 容器镜像中可保留
HEALTHCHECK指令，为编排系统提供标准化探测接口； - Swarm 使用
docker service create --restart-condition=on-failure --restart-max-attempts=5； - Kubernetes 在 Pod 或 Deployment 中声明
livenessProbe+restartPolicy: Always（后者对 Pod 默认即为 Always，通常无需显式写）； - 避免在
docker run命令中混用--restart=always，这在 Swarm/K8s 管理的容器中无意义，还可能干扰调试和日志归集。
