存活探针与发布的关系
Liveness 探针决定容器是否重启：连续失败达到阈值即由 kubelet 重启容器。它管的是「进程还活着吗」，与管流量的 readiness 探针职责不同；发布期间存活误配会让新实例反复重启，更新迟迟无法收敛，严重时滚动发布卡死在中间状态，旧副本不敢缩、新副本上不来。
基本信息
| 语义 | 失败即重启容器，不是摘流量 |
|---|---|
| 与就绪区别 | 就绪管流量，存活管重启 |
| 发布影响 | 存活失败导致重启循环，rollout 停留 |
| 原则 | 存活探针做低成本自检，不依赖外部系统 |
| 参数 | periodSeconds 与 failureThreshold 决定误杀敏感度 |
典型使用场景
- 存活自检：轻量接口验证进程未死锁。
- 慢启动保护：startupProbe 通过后才启用存活判死。
- 发布观察：用 rollout status 观察新实例是否反复重启。
- 探针调优：按业务响应时间设置检查周期与阈值。
- 故障恢复：卡死进程靠重启自愈，摘流治不了死锁。
存活探针
存活探针
livenessProbe:
httpGet: {path: /livez, port: 8080}
periodSeconds: 10
failureThreshold: 3三种探针对照
| 探针 | 失败后的动作 | 检查什么 |
|---|---|---|
| startup | 启动完成前不判死 | 启动较慢的应用 |
| readiness | 摘除流量 | 依赖就绪与处理能力 |
| liveness | 重启容器 | 进程自身健康 |
存活探针指向依赖数据库的接口时：数据库抖动会引发全量实例同时重启。
存活探针应检查进程自身，比如端口响应与死锁检测，不要依赖数据库、消息队列等外部系统。
failureThreshold 与 periodSeconds 决定误杀敏感度，上线前用真实启动时间验证，别照抄示例值。
排查入口：kubectl describe pod 的 Events 与重启计数，先分清是探针问题还是进程问题再改配置。
参数按生产验证：本地空跑通过不代表生产通过，探针周期与阈值用真实负载响应时间来定。