HEALTHCHECK指令是容器自我感知健康状态的基础，通过定期执行命令并依据退出码（0=healthy，1=unhealthy）判断状态，配合--interval、--timeout、--start-period、--retries等参数实现精准探活。
直接在镜像构建阶段嵌入健康检查和进程自愈能力，是让容器具备自动化故障恢复逻辑最可靠的方式。关键不在于运行时补救，而在于从根上让容器“知道自己怎么活下来”。
在Dockerfile中声明HEALTHCHECK指令
这是容器自我感知健康状态的基础。Docker会定期执行你定义的命令，并依据退出码判断状态：
- 0：健康（healthy）
- 1：不健康（unhealthy）
- 2：保留，不可用
推荐配置示例（适配常见Web服务）：
HEALTHCHECK --interval=30s --timeout=5s --start-period=15s --retries=3 \CMD curl -f http://localhost:8080/actuator/health || exit 1
说明：--start-period给应用留出启动缓冲时间，避免刚启动就被误判；--retries=3表示连续三次失败才标记为 unhealthy，防止瞬时抖动触发误操作。
选用支持进程监控的基础镜像
普通Alpine或Ubuntu镜像默认不带进程管理器，一旦主进程崩溃，整个容器就退出。改用具备自愈能力的基础环境更稳妥：
- 使用 baseimage-docker：内置
my_init和Runit，可自动拉起崩溃的子服务 - 或在自定义镜像中集成 supervisord / s6-overlay：通过配置文件定义服务依赖与重启策略
例如，在基于 baseimage-docker 的镜像中，只需把应用启动脚本放入 /etc/service/myapp/run，Runit 就会在进程退出后立即重启它，无需额外写脚本。
限制资源并配置优雅终止机制
很多故障源于资源耗尽（如 OOM），而非代码缺陷。合理约束 + 正确响应信号，能显著提升恢复成功率：
- 在 Dockerfile 或运行时加
--memory=512m --cpus=1.0防止单个容器拖垮宿主机 - 主进程需监听
SIGTERM并完成清理后退出，避免强制 kill 导致状态不一致 - Java 应用建议加 JVM 参数
-XX:+UseContainerSupport，使其正确识别容器内存限制
结合镜像构建与运行时策略协同生效
HEALTHCHECK 只负责“发现问题”，真正“恢复”靠的是运行时策略配合：
- 启动容器时必须指定
--restart=unless-stopped或--restart=on-failure:5 - 若使用 Kubernetes，需配合
livenessProbe（对应 HEALTHCHECK）与restartPolicy: Always - 避免单独依赖
always策略——若应用反复崩溃，不加健康检查可能陷入“重启→失败→再重启”死循环
也就是说，HEALTHCHECK 是“眼睛”，restart 策略是“手脚”，两者缺一不可。
