在容器化部署中，Docker 容器健康检查机制是保障服务可靠性的关键一环。无论你是运行单机容器还是编排大规模集群，健康检查都能帮你提前发现异常，避免流量被路由到故障实例。本文将从判断路径入手，逐步解析健康检查的实现原理、配置方法、失败条件与常见误区，帮助你构建自愈型容器服务。
判断路径：先明确健康检查的适用场景
在配置健康检查之前，你需要判断自己的场景是否需要它。如果容器只是短暂运行的任务（如批处理），或者你的编排系统（如 Kubernetes）已经提供了更高级的探针机制，那么 Docker 原生的 HEALTHCHECK 可能并非必需。但如果你运行的是长期服务的容器，且希望 Docker 能够自动标记容器状态，或者你的服务依赖外部依赖（如数据库），那么健康检查就是必备工具。
Docker 健康检查机制的核心：HEALTHCHECK 指令
Docker 的健康检查机制通过 Dockerfile 中的 HEALTHCHECK 指令实现。该指令定义了一个命令，Docker 会定期在容器内执行该命令，根据退出码判断容器是否健康：退出码 0 表示健康，非 0 表示不健康。此外，还有 --interval（检查间隔，默认 30 秒）、--timeout（超时时间，默认 30 秒）、--retries（连续失败次数，默认 3 次）和 --start-period（启动宽限期，默认 0 秒）等参数可调。这些参数共同决定了健康检查的敏感度和误报率。
配置示例：从简单到复杂
最简单的健康检查是使用 shell 命令，例如：
HEALTHCHECK --interval=30s --timeout=3s --retries=3
CMD curl -f http://localhost/ || exit 1
这里使用 curl 探测 HTTP 端点，如果请求失败则退出 1。但要注意，镜像中必须包含 curl，否则命令会因找不到程序而失败。更轻量的选择是使用 wget 或直接使用语言内置的 HTTP 客户端。对于非 HTTP 服务，可以检查 TCP 端口：
HEALTHCHECK CMD nc -z localhost 3306 || exit 1
或者检查进程是否存在：
HEALTHCHECK CMD pgrep myapp || exit 1
失败条件与常见误区
健康检查失败并不总是意味着服务不可用。例如，如果检查命令本身超时（比如 curl 在 DNS 解析上卡住），会导致误判。因此，设置合理的 --timeout 至关重要。另一个常见误区是使用过于复杂的检查命令，比如依赖外部脚本，这增加了失败概率。此外，某些服务在启动初期无法响应，如果 --start-period 设置过短，会导致容器被误杀。还要注意，健康检查只在容器运行期间有效，如果容器停止，状态会变为 “unhealthy” 但不会自动重启，除非你配置了重启策略。
与编排系统的集成：Kubernetes 探针
在 Kubernetes 中，健康检查通过 liveness 和 readiness 探针实现，它们与 Docker 的 HEALTHCHECK 有相似之处，但作用不同。liveness 探针决定是否重启容器，readiness 探针决定是否将流量路由到 Pod。Kubernetes 官方文档指出，Pod 是 Kubernetes 中最小的可部署计算对象，探针配置在 Pod 层面。虽然 Docker 的 HEALTHCHECK 可以被 Kubernetes 部分识别（作为容器状态），但 Kubernetes 更推荐使用原生探针，因为它们提供了更细粒度的控制。如果你使用 Docker Swarm，其健康检查直接依赖 Docker 的 HEALTHCHECK 状态。
健康检查的进阶实践
除了基本的 HTTP 探测，你还可以实现更复杂的检查逻辑，比如检查数据库连接、磁盘空间或业务关键路径。但要注意，检查命令应该在容器内执行，且不应依赖外部网络（除非业务本身需要）。另外，健康检查的输出日志会进入容器日志，可能产生大量噪音，建议将检查命令的输出重定向到 /dev/null。对于多阶段构建，你可以在最终镜像中只保留必要的工具，以减小镜像体积。
常见误区总结
- 忽略启动宽限期：导致容器在启动初期被误判为不健康。
- 检查命令过于复杂：增加失败概率和调试难度。
- 依赖外部服务：健康检查应关注自身进程，而非外部依赖。
- 忘记设置超时：命令卡住会拖慢检查节奏。
- 混淆 Docker HEALTHCHECK 与 Kubernetes 探针：在 Kubernetes 中应优先使用原生探针。
参考资料
延伸阅读