Kubernetes不使用Docker的HEALTHCHECK，而是通过livenessProbe和readinessProbe实现等效健康检测；二者执行主体不同，需手动对齐逻辑，推荐复用HTTP端点或脚本并确保返回码规范。
Kubernetes 不直接使用 Docker 的 HEALTHCHECK 指令，但可以通过合理配置探针（livenessProbe / readinessProbe）来实现等效的健康检测逻辑。关键在于：Kubernetes 探针运行在容器外部（由 kubelet 执行），而 Docker 的 HEALTHCHECK 是容器内部的自检机制，两者独立运行、互不感知。因此，不能“对接”或自动继承，但可以**手动对齐检测逻辑**。
理解两者的执行主体与生命周期差异
Docker 的 HEALTHCHECK 仅在 docker ps 或 docker inspect 中可见，只影响 docker run 启动的单机容器行为（如自动重启），在 Kubernetes 环境中被完全忽略。Kubernetes 的探针由 kubelet 调用，支持 exec、httpGet、tcpSocket 三种方式，其配置必须显式写在 Pod 或 Deployment 的 YAML 中。
- 容器启动后，Docker 的 HEALTHCHECK 可能持续运行，但 kubelet 完全不读取该状态
- Pod 的健康与否，只取决于 livenessProbe / readinessProbe 的返回结果
- 若未配置探针，Kubernetes 默认仅靠容器进程是否存活（PID 1 是否存在）判断 liveness
推荐做法：复用健康检查脚本或端点，而非依赖 HEALTHCHECK
最佳实践是将原本写在 Dockerfile 中的 HEALTHCHECK 命令（例如 CMD curl -f http://localhost:8080/health || exit 1）提取为独立脚本或 HTTP 接口，并在 Kubernetes 探针中复用同一逻辑：
- 在容器内提供
/healthz或/readyzHTTP 端点（如 Spring Boot 的/actuator/health），并在 readinessProbe 中用httpGet调用 - 若服务无 HTTP 接口，可编写轻量 shell 脚本（如
/usr/local/bin/check-health.sh），验证进程、端口、依赖服务连通性等，在 livenessProbe 中用exec方式调用 - 确保脚本返回码符合规范：成功返回 0，失败返回非 0（kubelet 严格依赖 exit code 判断）
示例：从 Dockerfile HEALTHCHECK 迁移到 Kubernetes 探针
假设 Dockerfile 中有：
HEALTHCHECK --interval=30s --timeout=3s CMD wget --quiet --tries=1 --spider http://localhost:3000/health || exit 1
对应 Kubernetes Deployment 应配置：
livenessProbe:
httpGet:
path: /health
port: 3000
initialDelaySeconds: 60
periodSeconds: 30
timeoutSeconds: 3
readinessProbe:
httpGet:
path: /health
port: 3000
initialDelaySeconds: 10
periodSeconds: 10
timeoutSeconds: 3
- 路径、端口、超时时间、频率均与原 HEALTHCHECK 对齐，保证行为一致
-
initialDelaySeconds需根据应用冷启动时间设置，避免 probe 过早触发重启 - HTTP 探针会自动校验响应状态码（2xx / 3xx 视为成功），无需额外解析 body
注意事项与常见陷阱
- 不要在容器内同时运行 HEALTHCHECK 和探针脚本并竞争资源（如频繁访问数据库），应统一由探针控制健康评估节奏
- 避免在 readinessProbe 中执行耗时操作（如完整依赖链检查），否则可能导致滚动更新卡住；可拆分为轻量就绪检查 + 后台异步健康上报
- exec 探针中慎用相对路径或未声明的命令（如
curl），需确保容器镜像中已安装且在 PATH 中 - 若应用本身已暴露标准健康端点（如 Prometheus 的
/metrics或 Envoy 的/server_info），优先复用，减少自定义逻辑
