Spring Boot应用在K8s的探针配置指南：从健康检查接口到就绪探针落地

Spring Boot应用在K8s的探针配置指南：从健康检查接口到就绪探针落地

最近在帮几个团队做云原生迁移，发现一个挺普遍的现象：很多Java开发者把Spring Boot应用往Kubernetes里一扔，配个简单的存活探针就觉得万事大吉了。结果呢？流量切换时偶发502，滚动更新时服务抖动，甚至出现“僵尸”Pod——进程活着，但已经不响应请求了。这些问题，十有八九都跟探针配置不到位有关。

Kubernetes的探针机制，远不止是让容器“活着”那么简单。它是一套精细化的流量控制与自愈体系，尤其对于Spring Boot这类JVM应用，启动慢、预热时间长、依赖服务多等特点，让探针配置成了保障服务稳定性的关键一环。这篇文章，我就结合自己趟过的坑，聊聊如何为Spring Boot应用设计一套既安全又高效的探针方案，把健康检查接口的价值真正发挥出来。

1. 理解Kubernetes探针：不只是“心跳检测”

很多人把Kubernetes的探针简单理解为“心跳检测”，这其实低估了它的设计初衷。在微服务架构下，一个Pod的生命周期管理远比“生与死”复杂。我们需要区分三种状态：进程在运行、应用已初始化完毕、应用已准备好处理流量。这三种状态分别对应Kubernetes提供的三种探针。

1.1 三种探针的核心职责与区别

先明确一个概念：探针是Kubelet对容器内应用状态的主动查询，而非应用的被动上报。它们的触发时机和作用截然不同。

• 启动探针：这是应用的“入场券”。它只关心一件事：我的主进程启动成功了吗？ 对于Spring Boot应用，这通常意味着JVM已经成功启动，SpringApplication.run()方法执行完毕，应用上下文开始初始化。在启动探针成功之前，存活探针和就绪探针都不会启动。这完美解决了JVM应用启动慢的问题——你可以给它足够长的initialDelaySeconds和failureThreshold，让它慢慢启动，而不会因为启动期间的“不健康”状态被误杀。
• 存活探针：这是应用的“生命线”。它持续检查：我的核心功能还正常吗？ 如果存活探针连续失败，Kubernetes会认为应用陷入了不可恢复的故障（比如死锁、内存泄漏导致功能瘫痪），进而重启容器。它的目标是保证单个实例的可用性。
• 就绪探针：这是应用的“流量开关”。它判断：我现在能安全地接收外部请求了吗？ 即使应用进程活着，也可能因为正在加载缓存、等待数据库连接、或执行数据迁移而无法处理业务请求。就绪探针失败，Kubernetes会将该Pod从Service的Endpoints列表中移除，确保流量不会打到尚未准备好的实例上。它的目标是保证整个服务的可用性。

用一个表格来直观对比：