三类探针是什么
健康检查分三类，职责完全不同：就绪检查决定实例是否接收流量，失败只会被摘出流量入口；存活检查决定实例是否需要重启，失败会杀掉容器；启动检查保护慢启动应用，在它成功之前其他两类检查不生效。搞混职责会让稳定性越治越差。
基本信息
| 就绪检查 | 失败时从流量入口摘除，不重启容器 |
|---|---|
| 存活检查 | 失败时重启容器，用于死锁、假死等场景 |
| 启动检查 | 成功前其他检查不生效，专治慢启动被误杀 |
| 通用参数 | 探测周期、超时时间、失败阈值与成功阈值 |
| 探测方式 | HTTP 请求、TCP 连接、命令执行三种 |
| 排查入口 | 事件里会记录检查失败的次数与时间 |
典型使用场景
- 流量摘除：依赖未就绪时先不接收请求，恢复后自动加回
- 自动恢复：进程假死或死锁时重启容器恢复服务
- 保护慢启动：给初始化耗时长的应用留足时间，避免反复被杀
- 发布安全网：就绪检查不通过时发布不会推进，问题版本不会全量
- 配合优雅退出：就绪检查先失败摘流量，再走停止流程减少请求失败
- 排障取证：从事件里确认失败时间点，与业务日志对齐
探针职责对照
| 探针 | 失败后果 | 典型场景 |
|---|---|---|
| 就绪检查 | 从流量入口摘除，不重启 | 依赖未就绪时临时摘流 |
| 存活检查 | 重启容器 | 死锁、卡死自动恢复 |
| 启动检查 | 按较长阈值判定并重启 | 慢启动应用防误杀 |
| 三者组合 | 各有阈值互不干扰 | 生产环境的常规配置 |
探针配置示例
探针配置示例
containers:
- name: web
image: registry.example.com/team/web:1.2.3
readinessProbe:
httpGet: { path: /healthz, port: 8080 }
periodSeconds: 5
failureThreshold: 3
livenessProbe:
httpGet: { path: /livez, port: 8080 }
periodSeconds: 10
failureThreshold: 3
startupProbe:
httpGet: { path: /healthz, port: 8080 }
periodSeconds: 5
failureThreshold: 60
# 存活检查只应判断进程自身是否还在工作把依赖状态写进存活检查是经典错误：数据库或缓存抖动会让全部副本同时重启，形成连锁故障，存活检查只应判断进程自身活性。
就绪检查不要做重活：探测本身执行复杂查询会拖慢服务，表现为延迟曲线与探测周期高度相关。
慢启动应用先配启动检查：没有启动检查时，初始化时间超过存活检查阈值就会被反复重启，日志看起来像是代码有缺陷。
探针失败会在事件里留痕：拿到失败时间点后与业务日志对照，能快速区分是应用问题还是探测配置问题。
探针参数怎么定
- 按应用真实就绪时间设置初始等待与失败阈值，不要凭感觉给数
- 就绪检查周期短一些能更快摘流，代价是探测开销增加
- 存活检查周期长一些，避免短暂卡顿引发不必要的重启
- 超时时间要小于探测周期，否则判定区间会相互重叠
- 启动检查阈值按最慢启动时间设置，并留出一定余量
- 探测路径要用轻量接口，避免探测本身消耗大量资源
- 上线前用真实流量验证一次摘流与恢复的完整过程
探针参数调整要留记录：改了哪些阈值、为什么改、改完观察到什么，值班时才能判断当前行为是否符合预期。
探针失败痕迹要留档：事件与日志过期之后就再没有依据判断当初是配置问题还是应用问题，复盘会变成猜测。