存活探针是什么
存活探针用来判断容器里的进程是否还能正常工作：检查连续失败达到阈值后，kubelet 会重启容器。它的判断标准应该是「进程自身是否卡死」，因为重启是代价很高的动作。一旦把可恢复的外部依赖问题写进存活检查，短暂的抖动就会被放大成大面积重启。
和就绪检查的分工
存活检查决定是否重启，就绪检查决定是否接流量，两者目标不同。依赖下游暂时不可用、应用正在预热，这类情况应交给就绪检查摘流量；进程死锁、无法再处理任何请求，才交给存活检查。把两者混用，会让局部故障演变成全局重启风暴。
基本信息
| 适用环境 | 任何 Kubernetes 发行版，写在容器的探针字段里 |
|---|---|
| 检查方式 | HTTP 请求、TCP 连接或容器内执行命令 |
| 关键参数 | 初始延迟、检查周期、超时时间、失败阈值 |
| 超限行为 | 重启容器，重启计数增加 |
| 与就绪的区别 | 存活失败会重启，就绪失败只摘流量 |
| 对象选择 | 只应检查本容器进程自身的健康状态 |
典型使用场景
- 防止死锁：进程卡住但端口还在监听时，靠检查接口主动发现问题
- 长时间运行的服务：网络或并发异常导致的软故障，重启可恢复
- 队列消费者：确认消费循环仍在推进，而不是静默停止
- 常驻代理进程：确保主循环没有意外退出并挂起
- 启动较慢的服务：配合初始延迟与启动探针，避免启动期被误判
- 配合优雅退出：确认重启前的终止流程能正常执行
HTTP 探针示例
HTTP 探针示例
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 15 # 给应用启动留出时间
periodSeconds: 10 # 检查频率
timeoutSeconds: 2 # 单次检查超时
failureThreshold: 3 # 连续失败几次才重启
successThreshold: 1 # 恢复判定所需次数观察重启
观察重启
kubectl describe pod web-x | grep -i -A6 liveness # 看探针配置与失败记录
kubectl get pod web-x -o jsonpath='{.status.containerStatuses[0].restartCount}' # 重启次数
kubectl get events --field-selector reason=Unhealthy --sort-by=.lastTimestamp | tail -10参数与影响
| 参数 | 作用 | 设置不当的后果 |
|---|---|---|
| initialDelaySeconds | 容器启动后多久开始检查 | 过短会在启动期被判死，反复重启 |
| periodSeconds | 检查间隔 | 过短增加负载，过长发现故障慢 |
| timeoutSeconds | 单次检查超时 | 过短会把正常慢响应判定为失败 |
| failureThreshold | 连续失败几次才动作 | 过小会因偶发抖动触发重启 |
设计检查接口的原则
- 只反映进程内部状态，不查询数据库或下游服务
- 响应要快，避免探针自身超时被记为失败
- 真正的依赖健康交由就绪检查与监控负责
检查接口应只反映进程内部状态，不要在其中查询数据库或下游服务，那些属于就绪检查关心的范围。
把存活检查指向依赖外部服务的接口，会让下游抖动直接触发全量重启，把局部故障放大为全局不可用。