Kubernetes Readiness Probe就绪探针报Unhealthy失败原因排查

这个问题本质是探针触发时机早于业务服务就绪时间，和你手动执行命令的运行阶段完全不一样，几个明确的诱因：

• 探针初始等待时间过短：当前配置initialDelaySeconds=10s，也就是容器启动10秒后就开始跑检测脚本，但Rustici Engine是Java类应用，启动需要加载组件、初始化连接、完成端口监听，10秒根本不够。第一次探针触发时8080端口还没被业务进程绑定，curl发起连接直接被拒绝，才会返回000的状态码，根本拿不到预期的401响应。你手动进Pod执行命令时，服务已经启动完成，端口正常监听，当然能跑通。
• 探针超时时间设置不合理：当前timeoutSeconds=5s，kubelet到点会直接强制终止整个探针进程，不会等curl慢慢等连接。加上你脚本里的curl没有设置自身超时，默认超时远大于5秒，一旦服务响应慢就会直接被判定失败。
• 内存配额不足拖慢启动：当前容器内存request/limit都卡到350Mi，Java应用启动阶段内存占用高，配额不足会触发频繁GC，进一步拉长启动时间，直接错过探针的初始等待窗口。

直接按以下顺序调整即可：

1. 调整探针参数：
   • 把initialDelaySeconds从10s上调到45~60s，给业务留足启动时间
   • 把timeoutSeconds从5s上调到10s，给curl请求留够响应时间
   • 给curl增加显式超时参数，对齐探针超时逻辑，避免残留进程，把脚本里的curl命令改成：

     curl -s -m 5 -o /dev/null --write-out "%{http_code}" http://localhost:8080/api/v2/ping
     

     其中-m 5代表curl自身最多等5秒，比kubelet的探针超时短，能保证正常返回状态码。
2. 资源配置优化：把容器内存limit上调到512Mi以上，如果启动还是慢可以调到1Gi，避免启动阶段内存不足。

重新发布负载后观察Pod事件：

• 启动前40秒左右不会再有探针报错
• 超过初始延迟后，Pod的Ready状态会自动变为True
• 后续探针检测不会再出现Unhealthy的事件

内容的提问来源于stack exchange，提问作者batupaksoy