高可用容器故障自动恢复的关键在于设计阶段嵌入自愈能力：启动时用--start-period=30s避开初始化误判，运行时区分liveness（触发重启）与readiness（控制流量），退出时依退出码选用on-failure或unless-stopped策略，并通过Compose或K8s实现跨节点调度级恢复。
高可用容器的故障自动恢复，关键不在“出了问题再修”，而是在设计容器生命周期时就嵌入自愈能力。从启动、运行到异常退出，每个阶段都要预设检测点和响应动作，让系统自己判断、自己决策、自己执行。
启动阶段：用健康检查缓冲期规避误判
容器刚启动时，应用可能还没完全就绪（比如数据库连接未建立、缓存未加载），直接探测容易误标为“不健康”。Docker 的 start-period 参数就是为此设计的——它给应用一段“冷静启动时间”，期间健康检查不计入失败计数。
- 推荐配置：
--start-period=30s，尤其适用于 Spring Boot、Node.js 等初始化较慢的服务 - 搭配
--retries=3和--timeout=5s，避免因瞬时网络抖动或依赖延迟导致重启 - 健康检查命令要真实反映业务就绪状态，例如检测
/health/ready而非仅/
运行阶段：区分存活与就绪，避免流量误入
只靠一个“是否活着”不够。高可用要求两个维度判断：容器进程是否在跑（liveness），以及它是否准备好服务请求（readiness）。Docker 原生只支持 healthcheck（类似 liveness），但在 Kubernetes 或 Compose 中可分开配置。
- Liveness 探针失败 → 触发重启：例如 HTTP 返回 5xx 或超时，说明进程卡死或崩溃
- Readiness 探针失败 → 暂停流量接入：例如 DB 连接断开但进程仍在，此时不应转发请求，但也不必立即重启
- 两者间隔建议错开：liveness 检查稍宽松（如每 10 秒），readiness 更频繁（如每 3 秒）
退出阶段：按退出码选择重启策略，不盲目重试
容器退出不是非黑即白，退出码藏着关键线索。Docker 的 on-failure 策略能根据实际退出码决定是否重启，比 always 更安全、更可控。
- 退出码 0：正常退出（如主动 shutdown），
on-failure不重启，符合预期 - 退出码 1–127：应用错误（如 panic、配置错误），
on-failure:3最多重试 3 次，防止死循环 - 退出码 137（SIGKILL）、143（SIGTERM）：通常是资源被杀或手动停止，
unless-stopped更适合这类守护型服务
编排层协同：让恢复动作不止于单机重启
单机 --restart 只解决进程级问题。真正高可用需要编排平台介入，把“恢复”升级为“调度”：
- Docker Compose 中设置
restart: unless-stopped+healthcheck，实现本地自愈 - Kubernetes 中用 Deployment 管理副本，配合
livenessProbe自动 kill 并重建 Pod - 当节点失联或磁盘满载，K8s 会将新 Pod 调度到健康节点，这是单机 Docker 做不到的弹性迁移
