livenessProbe 把健康 Pod 一直重启 initialDelay 太短

这个坑值得记一笔。K8s 1.25 上一个 Node 服务启动要加载两万条缓存，Pod 每分钟被重启一次，describe 里是 Liveness probe failed: connection refused，日志里应用其实跑得好好的。

刚开始盯着「failureThreshold 默认 3 次，配合 5 秒间隔，二十秒内就触发重启」，折腾了半个多小时，排掉了。

这类报错背后常见的原因有几处，逐个排除就行。livenessProbe 的 initialDelaySeconds 只有 5 秒，应用还没监听端口就被判死；timeoutSeconds 设成 1 秒，GC 停顿一下探针就超时；探针用的是 HTTP 检查但应用只开了 gRPC 端口，连接一直被拒。

从事件里确认是哪种探针失败

kubectl describe pod web-0 | grep -i -A3 'Liveness\|Readiness'

随后按真实启动耗时调整初始延迟

kubectl patch deploy web --type=json -p '[{"op":"replace","path":"/spec/template/spec/containers/0/livenessProbe/initialDelaySeconds","value":60}]'

再往下放大超时与失败次数

kubectl patch deploy web --type=json -p '[{"op":"replace","path":"/spec/template/spec/containers/0/livenessProbe/timeoutSeconds","value":5}]'

等前面都确认过，再观察重启计数是否归零

kubectl get pod -l app=web -o custom-columns=NAME:.metadata.name,RESTARTS:.status.containerStatuses[0].restartCount

怎么算真的好了，看的是同一批现象。重启计数在随后半小时内保持为 0，Pod 的 AGE 超过探针周期，事件里不再出现 Liveness probe failed。

这里还有个坑。存活探针只该判断进程是否卡死，把依赖数据库也塞进去会连锁重启；启动慢的服务用 startupProbe 兜住，比一味加大延迟更准。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。