服务没准备好，还是卡死了？一个健康检查不能决定一切

技术来源：Kubernetes 官方探针文档。以下设计是独立建议，不是可直接套用的配置。

“能接收新请求吗？”与“是否卡住到必须重启？”不是同一问题。混在一起，可能把短故障扩大。

分清角色

• Readiness 用于决定接收流量。
• Liveness 检测运行策略可能以重启回应的状态。
• Startup 关注应用初始化需要的时间。

不要直接推广到所有环境。别的工具显示 unhealthy，不代表采取相同动作，应阅读对应策略。

假设示例

数据库短暂不可用。若每次连接失败都让存活检查失败，健康应用也可能不断重启。丢失已预热状态会加重依赖故障。

我建议不要把不必要依赖放进强制存活决定。就绪检查也应符合服务需求，而非只看端口打开。

启用之前

在测试环境演练慢启动、过载和暂时依赖中断，同时测量探针本身成本。记录成功条件、等待时间和告警负责人。

补充阅读：Ping 之外的真实服务健康。

来源核查：2026年11月2日。场景是假设，不提供通用阈值或所有服务的重启建议。