分布式计算任务在Docker中实现自愈需贯穿镜像、运行、编排三层：镜像中用HEALTHCHECK定义业务级健康检查并设合理start-period；运行时配置unless-stopped重启策略；编排层通过Kubernetes的livenessProbe/readinessProbe实现跨节点容灾，并确保任务支持幂等重试。
要让分布式计算任务在 docker 容器中具备自愈能力，关键不是“等它挂了再修”，而是提前定义好“什么算健康”“什么算失败”“失败后怎么恢复”。这需要把状态管理贯穿在镜像构建、容器运行和任务编排三个层面，形成闭环。
在镜像里埋好健康探针
分布式计算任务（比如 Spark worker、Celery worker 或自定义批处理脚本）往往启动快但运行期依赖多——数据库连不上、中间件不可达、本地缓存损坏，都可能导致任务卡死或静默失败。光靠进程存活检测没用，必须深入业务逻辑层做判断。
在 Dockerfile 中加入 HEALTHCHECK 指令，指向一个能反映真实计算能力的端点或脚本：
- 如果是 Web 化任务服务，暴露 /health 接口，检查核心依赖（如 Redis 连通性、临时磁盘空间、任务队列长度）
- 如果是命令行类任务（如 Python 脚本持续消费 Kafka），写一个轻量 healthcheck.sh：检测进程是否存在、最近 5 分钟是否有新日志输出、关键临时文件是否可读写
- 示例配置：HEALTHCHECK --interval=20s --timeout=5s --start-period=60s --retries=2 CMD ./check-compute-ready.sh
注意 start-period 要设足够长（比如 60 秒），给计算任务完成初始化、加载模型、连接集群留出缓冲时间，避免刚启就误判为不健康。
用 restart 策略兜住基础恢复
健康检查只能标记状态，真正触发动作靠重启策略。对长期运行的计算节点，推荐使用 unless-stopped：
- 容器因 panic、OOM 或主动 exit 退出时，Docker daemon 自动拉起新实例
- 宿主机重启后，该容器也会自动启动，无需人工干预
- 区别于 always，它尊重运维人员手动 stop 的意图，更可控
启动命令示例：docker run -d --restart unless-stopped --name spark-worker-01 ... spark-worker:latest
在编排层实现跨节点容灾
单机上的自愈只是起点。真正的分布式高可用，要求某个节点失效时，任务能被调度到其他健康节点继续执行。这就必须脱离裸 docker run，进入编排阶段：
- 用 Docker Compose 时，在 service 下同时声明 healthcheck 和 restart，并配合 deploy.restart_policy（Swarm 模式下生效）
- 生产环境强烈建议上 Kubernetes：用 Deployment 管理副本，配置 livenessProbe（对应 Docker HEALTHCHECK）和 readinessProbe；Kubelet 发现不健康后，会终止 Pod 并在其他节点新建，整个过程对上层任务调度器透明
- 关键点：确保你的计算任务支持“断点续传”或“幂等重试”，否则单纯重启容器可能造成任务重复或丢失
把健康状态接入监控闭环
自愈不是黑盒。你需要知道“它为什么反复不健康”，否则可能掩盖深层问题。
- 用 docker inspect
| jq '.State.Health' 查看实时健康日志，包括每次检查的起止时间、退出码、输出内容 - 将容器健康状态（healthy/unhealthy）、FailingStreak 计数、重启次数等指标，通过 cAdvisor + Prometheus 抓取并告警
- 设置规则：比如“连续 3 次 unhealthy 且重启间隔＜10 秒”，说明不是偶发故障，而是配置或依赖问题，应触发人工介入而非继续盲等自愈
