ReadinessProbe 是 Kubernetes 中控制流量是否进入 Pod 的关键机制，它只决定 Pod 是否加入 Service 的 Endpoint 列表，失败时摘流、恢复后加回；支持 HTTP GET、TCP Socket 和 Exec 三种探测方式，需按应用特性选择；核心参数 initialDelaySeconds、periodSeconds、timeoutSeconds、failureThreshold 和 successThreshold 需合理配置以避免误判；其检查目标是“能否正确处理请求”，须验证核心依赖而非仅返回固定字符串，并应与 LivenessProbe 分离使用。
ReadinessProbe 是 Kubernetes 中控制流量是否进入 Pod 的关键机制。它不决定容器是否重启，只决定这个 Pod 是否该出现在 Service 的 Endpoint 列表里——失败时自动摘流，恢复后重新加回。
三种探测方式怎么选
根据应用特性选择合适的方式，避免误判：
-
HTTP GET（最常用）：适用于提供 HTTP 服务的应用。探针向指定 path 发起 GET 请求，返回 2xx 或 3xx 状态码即视为就绪。例如：
/ready或/health/ready - TCP Socket：只检查端口是否可连接，适合无 HTTP 接口但需确认监听状态的场景（如数据库代理、gRPC 服务）。不验证业务逻辑，轻量但不够精确
- Exec 命令：在容器内执行 shell 命令，返回码为 0 才算成功。适合无法暴露网络接口的离线型或批处理类容器
核心参数设置要点
参数配得不合理，容易导致“假未就绪”或“假就绪”，影响服务可用性：
- initialDelaySeconds：容器启动后等多久再开始探测。必须大于应用冷启动耗时（比如加载大模型、连 DB、初始化缓存），否则一上来就失败，反复摘流。常见值 10–60 秒
- periodSeconds：两次探测间隔。太短（如 1s）会增加 kubelet 和应用负担；太长（如 60s）会导致故障响应延迟。一般设为 5–15 秒
- timeoutSeconds：单次探测超时时间。应略大于健康接口平均响应时间（建议加 2–3 倍余量），避免网络抖动误判。默认 1 秒，多数 HTTP 场景建议设为 3–5 秒
- failureThreshold：连续失败多少次才标记为 NotReady。设为 2–3 比较稳妥，避免偶发超时导致误摘流
- successThreshold：从失败恢复时，需连续成功几次才算真正就绪。默认是 1，一般无需修改
Readiness 探针要检查什么
它不是“应用是否在跑”，而是“应用是否能正确处理请求”。所以健康接口必须反映真实就绪状态：
- 检查自身核心依赖是否可用（如数据库连接池 ready、Redis 连通、下游关键服务响应正常）
- 避免只返回固定字符串或时间戳——这类接口无法反映真实状态
- 不要把 Liveness 和 Readiness 逻辑混用：Readiness 不该触发重启，也不该因内存高而失败（那是 Liveness 的事）
- 如果应用启动慢，建议配合 startupProbe 使用，让 Readiness 在真正稳定后再启用
一个典型 YAML 配置示例
以下是一个带注释的 readinessProbe 片段，适配常见 Web 应用：
readinessProbe:
httpGet:
path: /ready
port: 8080
httpHeaders:
- name: X-Health-Check
value: "true"
initialDelaySeconds: 15
periodSeconds: 10
timeoutSeconds: 4
failureThreshold: 3
successThreshold: 1 
