Kubernetes Pod 探针：liveness / readiness / startup 该用哪一个

一、为什么需要探针

容器里的进程可能"活着但已经不能用了"：JVM 内存打满开始频繁 Full GC、Redis 主从断了只读、Python 服务因为一次坏请求把线程池取光。K8s 不会主动判断这些，它只能看到进程还在，于是继续把流量打过来，故障被放大，排查时又看不到任何异常日志。探针的作用，就是给 kubelet 一个定期问诊的机会：问一次，根据结果决定要不要重启容器、要不要把它从 Service 后端摘掉。

二、三种探针的职责分工

一句话区分：startup 管"什么时候算启动完成"，readiness 管"能不能接流量"，liveness 管"还能不能抢救"。只做部署不做流量的应用（比如批处理）通常只需要 startup + liveness。

三、一个最小可用的配置

livenessProbe:
  httpGet:               # 也可以用 tcpSocket 或 exec
    path: /healthz
    port: 8080
  initialDelaySeconds: 30      # 启动后多久开始第一次探测
  periodSeconds: 10            # 每 10 秒探测一次
  timeoutSeconds: 3            # 单次探测超时 3 秒
  successThreshold: 1          # 连续 1 次成功即恢复
  failureThreshold: 3          # 连续 3 次失败触发重启
readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  periodSeconds: 10
  failureThreshold: 3
startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  failureThreshold: 30
  periodSeconds: 10

三条探针可以共用同一路径，但语义不同：启动完成后就不再有 startup 的额外"宽容期"，如果 liveness 的 initialDelaySeconds 设得太小，慢应用会被反复重启——这几乎是最常见的生产事故。

四、参数逐个解释

• initialDelaySeconds：仅对第一次探测生效，不是"延迟接受流量"。liveness 设 30、startup 设 300，意味着启动初期不会因为还没起来就被判死。
• periodSeconds：全局节奏，最小 1 秒，默认 10 秒。探针的 HTTP 请求本身有超时，周期不能小于超时，否则请求还在跑就被下一个覆盖。
• timeoutSeconds：必须小于请求实际耗时上限，否则永远判定超时；但设得太小会误杀正常的慢查询接口。
• failureThreshold：连续失败次数，不是连续时长。3 次失败 × 10 秒 = 30 秒内没好就重启，记得和业务恢复时间对齐。
• successThreshold：只有 liveness/readiness 在失败后重新计数时才有意义，一般保持 1。

五、常见误用与排查

误用一：用 liveness 做依赖检查。数据库重启期间 Pod 被判死，应用被 K8s 反复杀，恢复时间被拉长。依赖不可用的应该用 readiness 摘流量，而不是重启。

误用二：探针接口太慢。/healthz 里顺手做了健康缓存、Dashboard 汇总，一个接口 5 秒，必然被判定超时。健康检查接口要能立即返回，最多几毫秒。

排查顺序：先看 kubectl describe pod 里的 Events，确认是哪条探针、什么时候开始失败的；再看 kubectl get pod -w 的 Ready/Restarts 列判断是否重启过；最后登录 Pod 里用同样的命令手工探测一次，比如 curl -v localhost:8080/healthz，看返回码和耗时。

六、实用技巧

• 基础设施要自己写健康检查：Spring Boot 用 spring-boot-starter-actuator 暴露 /actuator/health，配合 management.endpoint.health.probes.enabled=true 会自动产出 liveness/readiness 端点。
• 启动阶段慢就只靠 startupProbe 兜住，不要用 liveness 的宽 initialDelay 掩盖问题——它会把"启动慢"变成"永远重启"。
• 优雅下线：readiness 摘流 + preStop sleep(5~10 秒) + terminationGracePeriodSeconds，可以显著减少滚动更新时的 502。
• 不要在探针里执行重业务，也不要用 exec 跑依赖外部网络的命令，容器内环境和初始化阶段差异很大。