探针为什么容易出错
探针配置只写几行，却直接决定容器被重启还是被摘出负载均衡，因此出错代价很高。高频问题是把外部依赖写进存活探测、端口或路径写错、探测周期过密，以及终止流程与探针互相干扰。同类现象背后的原因差别很大，需要按顺序核对。
基本信息
| 适用平台 | Kubernetes 1.20+，由节点上的代理执行探测 |
|---|---|
| 三类探针 | 启动、就绪、存活 |
| 失败后果 | 存活失败重启容器，就绪失败摘出流量 |
| 常见错误来源 | 探测目标、周期参数、终止流程 |
| 核对工具 | 描述 Pod 与容器内手工请求 |
坑位对照
| 坑位 | 表现 | 修正方向 |
|---|---|---|
| 存活探测查依赖 | 下游抖动引发重启风暴 | 依赖检查放就绪探测，存活只查自身 |
| 端口或路径写错 | 未达阈值前一直重启 | 对照容器实际监听端口与路由 |
| 探测周期过密 | 高频探测额外消耗资源 | 按业务容忍度设置秒级周期 |
| 终止与探针冲突 | 终止期内探测失败触发重启 | 先摘掉流量再执行终止钩子 |
快速核对
快速核对
kubectl describe pod web-x | sed -n '/Liveness\|Readiness\|Startup/,+6p' # 看三类探针配置
kubectl exec -it web-x -- wget -qO- http://127.0.0.1:8080/healthz # 容器内手工探测
kubectl get pod web-x -o wide # 重启次数与就绪状态
kubectl get events --field-selector involvedObject.name=web-x | tail -10 # 探针失败事件排查顺序
- 先看重启次数与就绪状态，判断是存活失败还是就绪失败
- 再看探针配置中的端口、路径与阈值是否与容器实际一致
- 然后在容器内手工请求健康接口，确认应用自身是否正常
- 最后核对终止流程：终止钩子是否长于宽限期导致被强杀
- 确认无误后再考虑上调阈值或更换探测方式
容器内手工请求能通，不代表节点上的代理能探通。注意应用监听地址是仅本机回环还是所有网卡，绑定回环时从容器外部发起的探测会失败。
看到 Pod 反复重启，先看探针配置再看应用日志：应用一切正常但被探针判死的情况非常常见，直接查业务日志会走弯路。