K8s就绪探针：你的应用，真的准备好接待流量了吗？

在Kubernetes中部署应用时，我们常常认为一个Pod一旦进入“Running”状态，就可以立即开始处理外部请求。然而，这是一个危险的误解。Pod进程启动成功，并不等同于应用内部的服务（如数据库连接池初始化、缓存预热、配置文件加载）已准备就绪。将流量导向一个“半成品”Pod，是导致服务波动、请求失败的常见根源。【K8s Readiness Probe 就绪探针配置】正是Kubernetes为解决此问题提供的原生健康检查机制。其核心价值在于，它允许你定义一个自定义的、应用级的“就绪”判断标准。只有当就绪探针检查成功时，Kubernetes才会将该Pod的IP地址添加到Service的端点列表（Endpoints）中，使其开始接收流量。这确保了只有真正准备好的Pod才会对外服务，是实现零停机部署、优雅启动和稳定性的关键基石。

一、 从一次线上故障说起：没有就绪探针的代价

让我们看一个在鳄鱼java技术团队早期遇到的真实案例。一个核心的Spring Boot支付服务进行了版本更新，新版本启动时需要从配置中心拉取规则并初始化一个耗时约15秒的本地缓存。

部署过程：
1. 新Pod（v2版本）启动，进程很快进入Running状态。
2. Kubernetes的Service立即将流量切到新Pod。
3. 然而，在最初的15秒内，应用的缓存尚未就绪。这期间涌入的所有支付请求，要么因依赖缓存而超时，要么因使用默认空值导致逻辑错误。
4. 结果：部署期间，支付失败率瞬时飙升至30%，持续约15秒，造成直接业务损失和用户体验灾难。

根本原因：Pod的“容器运行”状态与应用“业务就绪”状态之间存在时间差。缺少【K8s Readiness Probe 就绪探针配置】，导致流量过早打入。

部署后，我们为服务添加了就绪探针，指向一个专用于检查缓存状态的健康端点（`/actuator/health/readiness`）。此后，同样的部署再未引发故障。新Pod在完全初始化成功前，会一直处于“未就绪”状态，流量由旧Pod平稳承担。

二、 核心机制：就绪探针如何控制流量准入？

就绪探针是Kubelet定期对Pod中容器执行的诊断操作。其决策逻辑清晰而严格：

工作原理流程图：
Pod启动 -> 启动后等待`initialDelaySeconds` -> 开始执行就绪探针检查 -> 检查成功？ -> 是：Pod状态标记为Ready，IP加入Service Endpoints。 -> 否：Pod状态保持Not Ready，IP不从Endpoints移除（或一开始就不加入），持续等待下次检查。

关键影响：
- Service流量：Service的负载均衡器只会将请求分发给Endpoints列表中的Pod（即状态为Ready的Pod）。
- 滚动更新：在Deployment滚动更新时，新Pod必须通过就绪探针检查，才会被视为“可用”，然后旧Pod才会被终止。这保证了在更新过程中，始终有准备好的Pod处理请求。
- 与存活探针（Liveness Probe）的区别：存活探针失败会导致容器重启，是“救命”机制；就绪探针失败仅导致流量隔离，是“业务就绪”声明机制。

三、 三种探针类型详解与配置示例

Kubernetes提供了三种类型的就绪探针，以适应不同的检查场景。

1. HTTP GET 探针
最常见的类型。向容器的指定端口和路径发起HTTP GET请求。如果响应状态码在200到399之间，则视为成功。

readinessProbe:
  httpGet:
    path: /health/ready  # 应用暴露的健康检查端点
    port: 8080
    httpHeaders:
    - name: Custom-Header
      value: ProbeCheck
  initialDelaySeconds: 10  # 容器启动后等待10秒才开始探测
  periodSeconds: 5         # 每5秒执行一次探测
  timeoutSeconds: 2        # 探测请求超时时间为2秒
  successThreshold: 1      # 连续1次成功视为就绪
  failureThreshold: 3      # 连续3次失败视为未就绪

适用场景：任何提供HTTP服务的应用，如Web后端、RESTful API服务。这是鳄鱼java微服务架构中的标准配置。

2. TCP Socket 探针
尝试与容器指定的端口建立TCP连接。如果连接建立成功，则视为就绪。

readinessProbe:
  tcpSocket:
    port: 9300  # 例如，Elasticsearch的传输端口或自定义TCP服务端口
  initialDelaySeconds: 30
  periodSeconds: 10
  timeoutSeconds: 5

适用场景：不提供HTTP服务，但监听特定端口的应用，如数据库（MySQL, Redis）、自定义TCP协议中间件。

3. Exec 探针
在容器内执行指定的Shell命令。如果命令返回码为0，则视为成功。

readinessProbe:
  exec:
    command:
    - cat
    - /var/run/service.ready  # 检查一个特定文件是否存在
  initialDelaySeconds: 5
  periodSeconds: 5

适用场景：需要复杂自定义检查逻辑，或应用无法通过网络检查的情况。例如，检查某个特定文件是否由初始化脚本生成。

四、 关键参数调优：从粗糙到精确的艺术

一个有效的【K8s Readiness Probe 就绪探针配置】不仅在于选择类型，更在于精细调整参数。以下是每个参数的意义与调优指南：

一个生产级配置示例：对于一个需要15秒初始化的Java服务，配置如下：

readinessProbe:
  httpGet:
    path: /actuator/health/readiness
    port: 8080
  initialDelaySeconds: 20  # 给予充足初始化时间 
  periodSeconds: 5
  timeoutSeconds: 3
  successThreshold: 1
  failureThreshold: 3  # 容忍最多约15秒的临时故障

五、 高级模式与最佳实践

1. 与启动探针（Startup Probe）协同
对于启动极慢的应用（如遗留单体系统），仅用`initialDelaySeconds`可能不够，且会阻塞存活探针。Kubernetes 1.16+引入了Startup Probe，专门用于保护慢启动容器。

startupProbe:
  httpGet:
    path: /health/startup 
    port: 8080
  failureThreshold: 30  # 允许尝试很多次
  periodSeconds: 10     # 间隔较长
# 在startupProbe成功之前，livenessProbe和readinessProbe不会启动

2. 就绪探针端点设计
探针端点应进行最小化依赖检查。一个常见的错误是，将就绪探针指向一个检查了所有外部依赖（如数据库、Redis、MQ）的“总健康”端点。这会导致当任何一个外部依赖暂时故障时，整个Pod被流量隔离，丧失了应用的弹性（可能仍有部分功能可用）。理想的设计是：
- 就绪探针：仅检查应用内部状态（如线程池、内存状态、内部缓存）。
- 存活探针或业务健康端点：用于检查外部依赖，并触发告警，但不直接用于流量切断决策。

3. 就绪态≠永远健康
就绪探针在Pod生命周期内持续运行。这意味着，如果Pod在运行过程中出现内部故障（如内存泄漏导致服务能力下降），就绪探针应能检测到并使其“未就绪”，从而将流量引流到其他健康Pod。这是实现自我修复的重要一环。

六、 总结：构建韧性服务的必备基础设施

正确配置【K8s Readiness Probe 就绪探针配置】，是交付生产就绪（Production-Ready）应用的基本功。为了帮助你形成体系化的决策框架，请参考以下检查清单：

总而言之，就绪探针是Kubernetes赋予应用的一种“自我声明”能力。它让应用可以明确地告诉集群：“我好了，请把流量给我”或“我病了，请让我休息”。精心设计【K8s Readiness Probe 就绪探针配置】，是实现无缝滚动更新、优雅应对内部故障、构建高韧性分布式系统的关键一步。它从流量入口处设立了一道智能闸门，将不稳定的因素隔离在系统之外。

请立即检查你的K8s工作负载：Deployment、StatefulSet中的Pod是否都配置了恰当的就绪探针？`initialDelaySeconds`是否基于真实启动时间设定？探针检查的逻辑是否过于脆弱或沉重？将这些问题的答案落实到你的YAML文件中，是提升服务可靠性的最直接有效的手段。欢迎在鳄鱼java网站分享你在复杂微服务场景下设计就绪探针、处理慢启动应用以及与服务网格（如Istio）健康检查协同的实战经验。