EKS集群livenessProbe超时但手动执行正常问题求助

问题背景 #

在EKS v1.25.16-eks集群中，部分运行正常的工作负载Pod因存活探针超时被重启，kubelet报错如下：

Warning  Unhealthy  19m (x9 over 25h)     kubelet  Liveness probe failed: command "docker-healthcheck" timed out

当前探针的timeoutSeconds设为1秒，健康检查脚本内容如下：

#!/bin/sh
set -e

if env -i REQUEST_METHOD=GET SCRIPT_NAME=/health SCRIPT_FILENAME=/health cgi-fcgi -bind -connect localhost:9000; then
    exit 0
fi

exit 1

手动在容器内执行该脚本耗时远小于1秒，临时增大timeoutSeconds可解决问题，但需明确超时的根本原因。

可能的原因及验证方式 #

• kubelet节点资源不足：当EKS节点CPU、内存资源紧张时，kubelet无法及时调度进程执行探针脚本，或等待执行结果的过程被阻塞。可通过以下方式验证：

  • 查看节点kubelet日志：journalctl -u kubelet，检查超时时段是否有资源不足相关报错
  • 监控节点CPU、内存使用率，确认探针超时时段是否存在资源峰值

• 容器内应用资源竞争：应用进程（监听9000端口的服务）在GC、批量任务等场景下会短暂占用大量资源，导致cgi-fcgi请求无法及时响应。验证方式：

  • 监控容器内CPU使用率、应用请求处理延迟，查看超时时段是否存在资源占用高峰

• exec探针执行上下文差异：kubelet执行exec探针需通过容器运行时（如containerd）创建新进程，涉及命名空间切换、镜像层挂载等操作，在资源紧张时会增加额外开销。可在脚本中添加时间戳日志，对比手动执行与kubelet触发执行的耗时差异。

• cgi-fcgi工具连接特性限制：cgi-fcgi在连接localhost:9000时，若目标端口监听队列满、TCP连接建立延迟，会导致整体耗时超过1秒。可尝试替换为curl http://localhost:9000/health执行健康检查，对比两种方式的稳定性。

• 节点系统层面波动：EC2节点出现磁盘I/O过高、内核线程阻塞（如I/O等待）时，会影响本地回环请求的处理速度。验证方式：

  • 查看节点系统日志：dmesg，检查超时时段是否有I/O或内核相关报错
  • 监控节点磁盘I/O指标，确认是否存在I/O瓶颈

• 探针并发处理压力：节点上大量Pod同时执行探针时，kubelet的探针处理线程池可能被占满，导致探针请求排队超时。可查看节点上的Pod数量，结合kubelet默认的--max-probe-concurrent参数判断是否存在并发压力。

内容的提问来源于stack exchange，提问作者Mathieu Défosse