LivenessProbe 失败原因 → 解决办法对照表

📊 LivenessProbe 失败排查对照表

失败原因 典型表现 排查方法 解决办法
应用端口没监听 curl http://127.0.0.1:8080/healthz 不通 netstat -tlnp / ss -tlnp 查看端口 确认应用监听在正确端口
应用监听地址不对 探针访问 127.0.0.1，但应用只监听 0.0.0.0 或反之 查看 netstat 绑定的 IP 修改应用监听地址或调整探针 host 参数
应用启动慢 Pod 刚启动就报 livenessProbe failed 查看应用启动日志，是否 > initialDelaySeconds 增加 initialDelaySeconds
应用响应慢 日志显示 Client.Timeout exceeded 容器内执行 curl 看耗时 调大 timeoutSeconds，优化 /healthz 逻辑
探针路径错误 探针 404/403/500 curl 验证 URL 是否正确 修改探针 path，避免依赖鉴权
探针配置过严 偶尔网络抖动即失败 查看 failureThreshold 是否过低 增加 failureThreshold，放宽容忍度
容器 CPU/内存不足 kubectl top pod 显示资源高，探针超时 dmesg 或应用日志有 OOM 信息 提高 request/limit，优化应用
应用 GC/卡死 日志无响应，CPU 占用异常 应用内部监控/GC 日志 优化代码，增加健康检查接口独立性
CNI/网络异常 其他端口访问也超时 检查 kubelet 日志、CNI 状态 修复网络插件或节点问题

✅ 最佳实践

  • 探针接口要轻量级、无依赖（不要依赖数据库、外部 API）

  • livenessProbe 用来判断 进程卡死，readinessProbe 才是判断 服务是否可用

  • 建议配置：

    initialDelaySeconds: 10
periodSeconds: 10
timeoutSeconds: 5
failureThreshold: 5