探针失败怎么查
Pod 事件里出现 Unhealthy，说明 kubelet 按配置探测容器失败。这不一定代表应用坏了——也可能是探针本身写错了：路径不存在、端口用了宿主端口而不是容器端口、启动宽限期太短。判断方法很直接：进容器手动执行与探针完全相同的命令或请求，能通说明是探针配置问题，不通才是应用真的不健康。
基本信息
| 看事件 | kubectl describe pod 中的 Liveness 或 Readiness probe failed 记录 |
|---|---|
| 手动复现 | exec 进容器执行与探针相同的命令或访问同一个路径 |
| 三个关键参数 | initialDelaySeconds 太短、timeoutSeconds 太小、失败阈值太严 |
| 端口与路径 | 端口是容器端口而非宿主端口，路径需与应用实际路由一致 |
| 后果区分 | readiness 失败只是摘流，liveness 失败会触发重启 |
典型使用场景
- 服务不接流量：readiness 一直失败，Pod 处于未就绪状态被排除在端点之外
- 容器反复重启：liveness 判定失败导致循环重启，需要先看探针是不是误杀
- 启动慢的服务：初始化耗时较长，需要调整宽限期或使用启动探针
- 健康接口变更：应用升级后健康路径改名，探针指向了旧地址
- 偶发重启：健康接口依赖下游，下游抖动导致探针间歇失败
排查命令
排查命令
kubectl describe pod web-1 | grep -i -B2 -A2 "probe failed" | head -30
# 手动执行与探针相同的命令，确认应用与路径是否真的可用
kubectl exec web-1 -- wget -qO- http://127.0.0.1:8080/healthz | head -3
# 核对容器端口与探针端口是否一致
kubectl get pod web-1 -o jsonpath='{.spec.containers[*].ports}'
kubectl exec web-1 -- cat /proc/1/cmdline # 确认主进程确实是应用本身探针参数与现象对照
| 参数 | 作用 | 设置不当的表现 |
|---|---|---|
| initialDelaySeconds | 首次探测前等待时间 | 太短会导致启动期就判失败 |
| periodSeconds | 探测间隔 | 过长会延迟发现问题 |
| timeoutSeconds | 单次探测超时 | 太短会把慢响应判为失败 |
| failureThreshold | 连续失败多少次判异常 | 过严会因偶发抖动触发重启 |
| successThreshold | 连续成功多少次判恢复 | 过严会延长恢复时间 |
健康接口应当轻量且只反映自身状态：把依赖数据库或下游的判断放进存活探针，会把外部故障放大成整集群的重启风暴。
慢启动应用要配启动探针或足够长的初始等待：没有启动探针时，存活探针会在应用还没监听端口时判定失败并不断重启，形成永远起不来的死循环。