1. 为什么Spring Boot应用需要Kubernetes探针在微服务架构中Spring Boot应用的健康状态直接影响整个系统的稳定性。想象一下这样的场景你的Java应用因为内存泄漏导致响应缓慢但JVM进程还在运行或者应用启动时需要加载大量数据导致前几分钟根本无法处理请求。这时候如果没有健康检查机制Kubernetes会认为这些僵尸服务是正常的继续把流量导给它们。我遇到过最典型的问题是一个Spring Cloud Gateway服务启动时需要加载200多个路由规则整个过程耗时近2分钟。如果没有配置启动探针Kubernetes在Pod启动30秒后就开始转发流量结果大量请求直接失败。后来我们通过组合使用三种探针完美解决了这个问题。2. 三种探针的核心区别与适用场景2.1 存活探针Liveness Probe就像它的名字一样存活探针负责检查容器是否活着。当检测失败时Kubernetes会无情地杀掉这个容器并重新创建一个。我通常用这个来处理以下问题应用死锁比如数据库连接池耗尽内存泄漏导致的OOM虽然JVM进程还在但已经无法正常工作线程池满导致的请求堆积livenessProbe: httpGet: path: /actuator/health/liveness port: 8080 initialDelaySeconds: 30 periodSeconds: 102.2 就绪探针Readiness Probe这个探针决定了Pod是否准备好接收流量。与存活探针不同它不会杀死容器只是暂时把Pod从Service的负载均衡池中摘除。我在这些场景一定会用它应用启动时的初始化阶段缓存预热、数据库连接建立等依赖服务不可用时的熔断状态流量激增时的自我保护模式readinessProbe: httpGet: path: /actuator/health/readiness port: 8080 initialDelaySeconds: 5 periodSeconds: 52.3 启动探针Startup Probe这是Kubernetes 1.16引入的新探针专门解决慢启动应用的问题。它的特殊之处在于启动期间会暂时禁用其他探针成功后就会永久退出不再检查特别适合Spring Boot应用初始化场景startupProbe: httpGet: path: /actuator/health/startup port: 8080 failureThreshold: 30 periodSeconds: 103. Spring Boot健康检查接口的实战配置3.1 使用Actuator暴露健康端点Spring Boot Actuator已经内置了健康检查功能只需要在pom.xml中添加dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-actuator/artifactId /dependency然后在application.yml中配置management: endpoint: health: probes: enabled: true show-details: always endpoints: web: exposure: include: health3.2 自定义健康指标对于需要检查的特定组件可以继承AbstractHealthIndicatorComponent public class RedisHealthIndicator extends AbstractHealthIndicator { Override protected void doHealthCheck(Health.Builder builder) throws Exception { // 实现具体的健康检查逻辑 } }4. 生产环境最佳实践4.1 参数调优经验值根据我处理过的生产案例这些参数组合效果最好场景initialDelaySecondsperiodSecondsfailureThreshold常规服务30s10s3大数据量启动60s15s5关键核心服务10s5s14.2 必须避免的坑initialDelaySeconds设置过小曾经有个服务因为设置为5秒导致在GC暂停时被误杀检查接口性能问题有个健康检查接口执行了全表扫描直接把数据库拖垮未区分liveness和readiness把数据库连接检查放在liveness导致容器不断重启4.3 高级技巧分阶段配置对于特别复杂的应用我推荐使用分阶段配置startupProbe: httpGet: path: /actuator/health/startup port: 8080 failureThreshold: 30 periodSeconds: 10 readinessProbe: httpGet: path: /actuator/health/readiness port: 8080 initialDelaySeconds: 0 # 等startup成功后立即开始 periodSeconds: 5 livenessProbe: httpGet: path: /actuator/health/liveness port: 8080 initialDelaySeconds: 60 # 给足启动时间 periodSeconds: 105. 典型故障排查案例去年我们一个订单服务频繁重启查看事件日志发现Warning Unhealthy 3m kubelet Liveness probe failed: HTTP probe failed with statuscode: 503排查过程检查健康接口响应时间发现95线达到8秒发现健康检查里包含了对Redis集群的全节点检查其中一个Redis节点网络延迟高达2秒解决方案将Redis检查移到readiness探针liveness只检查应用基础状态调整后的配置livenessProbe: httpGet: path: /actuator/health/liveness port: 8080 periodSeconds: 10 readinessProbe: httpGet: path: /actuator/health/readiness port: 8080 initialDelaySeconds: 30这个案例让我深刻理解了不同探针的使用边界。现在团队有个规范所有Spring Boot服务必须配置三种探针且健康检查接口响应时间必须控制在1秒内。