Kubernetes就绪探针：高可用服务的守门人

在 Kubernetes 的世界里，探针（Probe）是应用健康管理的基石。其中，就绪探针（Readiness Probe）更是服务稳定上线的"守门人"。如果你曾遇到服务启动慢、K8s突然摘除正常Pod、流量异常中断等问题，那么掌握就绪探针的原理与用法，或许能让你的系统如虎添翼。

一、什么是就绪探针？

就绪探针是 Kubernetes 用来判断容器是否准备好对外提供服务的一种机制。

与存活探针（Liveness Probe）关注容器是否"挂了"不同，就绪探针只关心：当前这个 Pod 是否能正常处理请求？一旦探测失败，Pod 会被临时从 Service 的 endpoints 中摘除，从而停止接收请求，但不会被杀死。

它的本质是一种"流量开关机制"，让容器可以优雅"上岗"和"下岗"。

二、为什么需要就绪探针？

想象这样几个真实场景：

启动慢的服务
某些服务（如加载大模型、连接多个数据库）启动时间较长。如果在它真正准备好前就被加入 Service 接收请求，可能造成大量请求失败。
服务偶发卡顿或压力过载
服务短时间内处理能力下降，不适合继续接收流量，此时通过就绪探针可以暂时"请假"。
滚动更新中避免请求打到旧版本
滚动更新时，如果旧版本已经不再能正确处理请求，就绪探针可以帮助优雅退出。

总之，它是一把"交通指挥棒"，帮助 Kubernetes 动态调整流量入口，提升系统的稳定性和用户体验。

三、配置方式详解

Kubernetes 支持三种类型的探针方式：

类型	说明
HTTP Get	发起 HTTP 请求，判断返回状态码是否在 200-399
TCP Socket	尝试建立 TCP 连接，连接成功即认为成功
Exec	在容器中执行命令，返回码为 0 则为成功

下面是一个配置就绪探针的 YAML 示例：

yaml 复制代码

readinessProbe:
  httpGet:
    path: /healthz/ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10
  timeoutSeconds: 2
  successThreshold: 1
  failureThreshold: 3

字段说明：

initialDelaySeconds：容器启动后多久开始探测；
periodSeconds：探针探测的间隔时间；
timeoutSeconds：探测请求的超时时间；
successThreshold：判断恢复正常需要连续成功几次；
failureThreshold：判断不健康需要连续失败几次。

四、实战建议

1. 配合 readinessGate 做应用自检控制

K8s 提供了一个 readinessGate 机制，可以配合自定义条件控制就绪状态，比如等缓存预热完成后再上报 Ready。

yaml 复制代码

spec:
  readinessGates:
  - conditionType: "mycompany.com/ready"

应用只需设置好 Pod condition，K8s 会自动控制 Service 流量。

2. 慎用 exec 探针

exec 探针虽然灵活，但可能造成资源浪费。因为每次都要进入容器执行命令，对性能有一定开销，建议只在调试或特殊场景使用。

3. 监控与日志配合

开启探针后，要结合 Prometheus 或 ELK 对探针请求进行监控、追踪。探针失败时往往是问题的早期信号。

4. 避免与 Liveness Probe 冲突

就绪探针失败不会杀容器，但存活探针失败会。两者配置目标不同，应该避免混淆。比如不要用同一个接口同时作为就绪和存活探针，防止误杀。

五、常见误区解析

❌ 误区一：只配了就绪探针，就以为系统高可用了

就绪探针只是一个"入口筛选器"，并不等于故障恢复机制。高可用仍需依赖副本数、负载均衡、熔断等多层设计。

❌ 误区二：使用静态返回200的 /health 接口

有些团队用静态文件返回 200 作为就绪探针接口，这等于"形同虚设"。探针接口应该真实反映服务可用状态，如依赖服务连接是否正常、线程池是否可用等。

❌ 误区三：探针失败就立即排查服务故障

探针失败可能是预期内的状态（如服务维护、初始化），不一定就是 Bug。应结合服务日志和时间线分析。

六、总结

就绪探针并不是炫技的配置项，而是保障服务"只在健康时接受流量"的核心手段。它解决了 K8s 场景下服务上线、过载、维护等状态下的流量控制问题，是现代云原生架构中不可或缺的稳定器。

如果你还没给服务配置就绪探针，那么现在就是时候补上这一课了！