Kubernetes里，Readiness和Liveness探针，你用对了吗？🤔

本文将从设计目的、 工作机制、差异、示例、最佳实践、进阶玩法全方位讲解，并结合 Spring Boot 案例给出完整配置。准备好你的咖啡☕，别慌，下面的文字会像坐过山车一样起伏不定，啊这...。

一、为啥要有 Readiness & Liveness 探针？🤔

在没有健康检查之前，K8s 只能盲盲地把 Pod 当作“活着的尸体”。 于是出现了两大天才兄弟：，来日方长。

• Readiness Probe判断容器是否已经准备好接受流量，像门卫一样拦住“未成年”请求。
• Liveness Probe监测容器是否“自杀”，一旦挂掉就立刻叫人把它踢出集群。

简直了。 这俩玩意儿配合得好， 系统就能稳如老狗；配合得烂，整个集群可能瞬间变成“雪崩现场”。

1.1 设计初衷的那些小九九

换个角度。 Readiness 为流量控制服务，Liveness 为自愈保命符。 如果你只开 Liveness， 却不管 Readiness，那流量会直接冲进还在初始化的容器里——这叫流量炸弹。

二、工作机制——到底是怎么“嗅探”的？👃

简单来说... 两种探针本质上都是 kubelet → Pod → /health endpoint 的一次 HTTP/Exec/TCP 检查。