Spring Boot在Kubernetes中实现优雅探针的关键是：使用Actuator原生/liveness和/readiness端点，配置合理参数（如initialDelaySeconds、failureThreshold），区分语义——存活探针仅检查JVM主线程是否卡死，就绪探针检查依赖就绪与业务状态，慢启动应用必须启用startupProbe，并可按需自定义HealthIndicator。
Spring Boot 在 Kubernetes 中实现优雅的就绪与存活探针，关键不是“能通就行”，而是让探针真正反映应用的真实状态——既不误杀，也不放行“假活”实例。核心在于：用 Spring Boot Actuator 的原生健康端点 + 合理的探针参数 + 清晰的状态语义。
启用 Actuator 健康端点并暴露 Liveness/Readiness
从 Spring Boot 2.3.2 起，需显式启用对应指标：
- 添加依赖：
spring-boot-starter-actuator - 在
application.yml中配置：
management:
endpoint:
health:
probes:
enabled: true
endpoints:
web:
exposure:
include: health
health:
livenessState:
enabled: true
readinessState:
enabled: true
启用后，自动提供两个轻量、无副作用的专用端点：
/actuator/health/liveness（返回 {"status":"UP"} 或 {"status":"DOWN"}）
/actuator/health/readiness（同上，但语义不同）
在 Pod 中正确配置探针参数
避免直接复用 /actuator/health 全局端点——它可能包含数据库、Redis 等依赖检查，会干扰存活判断。
- 就绪探针应检查依赖就绪性（如 DB 连接池初始化完成、缓存预热结束），但不要包含“是否崩溃”类逻辑
- 存活探针只检查 JVM 进程是否卡死、主线程是否存活，绝不检查外部依赖（否则依赖故障会触发无意义重启）
- 典型 YAML 片段：
readinessProbe:
httpGet:
path: /actuator/health/readiness
port: 8080
initialDelaySeconds: 30
periodSeconds: 5
timeoutSeconds: 2
failureThreshold: 3
livenessProbe:
httpGet:
path: /actuator/health/liveness
port: 8080
initialDelaySeconds: 60
periodSeconds: 10
timeoutSeconds: 3
failureThreshold: 3
initialDelaySeconds 要足够长，给 JVM 和 Spring 上下文留出启动时间；failureThreshold × periodSeconds 决定了容忍失败的总时长，避免冷启动被误判。
配合启动探针应对慢启动 Java 应用
对于加载大模型、初始化海量缓存或执行数据迁移的 Java 应用，仅靠 initialDelaySeconds 不够稳健。应启用 startupProbe：
- 它会在容器启动后独占接管健康判断，直到首次成功
- 在此期间，liveness 和 readiness 探针完全不执行
- 推荐配置（宽裕但可控）：
startupProbe:
httpGet:
path: /actuator/health/startup
port: 8080
failureThreshold: 60
periodSeconds: 10
这样可允许最长 10 分钟启动时间，而不会因超时被 kill —— 比硬调大 initialDelaySeconds 更安全、更清晰。
自定义就绪逻辑（按需扩展）
默认的 ReadinessStateHealthIndicator 只反映 Spring 的上下文生命周期（如是否收到 ContextRefreshedEvent）。若业务有更精细要求，比如“等某个异步任务完成后再接受流量”，可注册自定义指示器：
- 实现
HealthIndicator接口，注入到 Spring 容器 - 在
health()方法中检查业务条件（如myAsyncTask.isDone()） - 确保该逻辑轻量、无阻塞、不抛异常
Spring Boot 会自动将其聚合进 /actuator/health/readiness 响应中，Kubernetes 就绪探针即可感知。
