五个参数决定探针节奏
探针行为完全由几个时间与次数参数决定：多久开始第一次探测、每隔多久探一次、单次等多久算超时、连续失败几次触发动作、失败后连续成功几次算恢复。把它们组合起来，就能算出从故障发生到做出反应的最坏时间，这也是调参时最该先估算的量。
基本信息
| 适用平台 | Kubernetes 1.20+，三类探针共用同一组参数 |
|---|---|
| 最坏发现时间 | 失败阈值乘以周期与超时之和 |
| 启动探针差异 | 通过后不再执行 |
| 存活探针限制 | 恢复所需成功次数只能为一 |
| 默认值风险 | 超时默认一秒，对慢接口偏紧 |
典型使用场景
- 接口响应较慢，需要调整超时避免误判失败
- 需要缩短故障发现时间，让流量更快被摘除
- 排查重启频率偏高：核对失败阈值与周期
- 为启动慢的应用设置独立的启动阶段预算
- 发布前核对探针参数，避免发布期频繁重建
参数速查
| 参数 | 默认值 | 含义 |
|---|---|---|
| 首次延迟 | 0 秒 | 容器启动后多久开始探测 |
| 探测周期 | 10 秒 | 两次探测之间的间隔 |
| 单次超时 | 1 秒 | 超过该时间算本次探测失败 |
| 成功阈值 | 1 次 | 失败后连续成功几次才算恢复 |
| 失败阈值 | 3 次 | 连续失败几次触发动作 |
计算示例
计算示例
最坏发现时间 ≈ 失败阈值 × (探测周期 + 单次超时)
例：3 × (10 + 2) = 36 秒后触发重启
例：摘流时间 = 3 × (5 + 1) = 18 秒，对延迟敏感的服务可缩短周期
参数示例：periodSeconds: 5 timeoutSeconds: 2 failureThreshold: 3核对生效值
核对生效值
kubectl get pod web-x -o jsonpath='{.spec.containers[0].livenessProbe}' # 存活探针
kubectl get pod web-x -o jsonpath='{.spec.containers[0].readinessProbe}' # 就绪探针
kubectl describe pod web-x | sed -n '/Liveness/,+6p' # 可读形式
kubectl get pod web-x -o jsonpath='{.status.containerStatuses[0].restartCount}'单次超时大于探测周期时，上一轮还没结束下一轮就开始了，时间线会变得难以解读。参数之间的相对关系比单个数值更重要。
成功阈值大于一时，从故障恢复到重新接收流量需要多次成功探测，摘流时间被拉长。对可用性敏感的接口应核算这段延迟。