本文探讨spring boot应用在kubernetes环境中启动后立即关闭的常见问题，并提供解决方案。核心原因在于kubernetes的liveness和readiness探针在应用完全启动并准备好接受流量之前过早失败。教程将详细解释liveness和readiness探针的作用，并通过配置initialdelayseconds来延迟探针检查，从而确保应用有足够时间完成初始化，避免被kubernetes误判为不健康而重启。
在将Spring Boot应用程序部署到Kubernetes环境时，开发者可能会遇到应用启动后立即关闭的现象。尽管应用在本地或开发环境运行正常，但在生产预发布（PP）等特定环境中，容器可能在启动几秒后就被终止并重启。这种行为通常是由于Kubernetes的健康检查机制与Spring Boot应用的启动时间不匹配所致。
理解Kubernetes健康探针
Kubernetes通过两种主要类型的探针来管理容器的生命周期和流量路由：
-
Liveness Probe（存活探针）：
- 目的：检测容器是否仍然存活并运行。如果Liveness探针失败，Kubernetes会认为容器已损坏，并根据重启策略将其重启。
- 场景：适用于应用程序可能进入死锁状态（例如，线程被卡住，但进程仍在运行）的情况。
-
Readiness Probe（就绪探针）：
- 目的：检测容器是否已准备好接收流量。如果Readiness探针失败，Kubernetes会将该Pod从Service的Endpoint列表中移除，停止向其发送流量，直到探针成功为止。
- 场景：适用于应用程序需要时间进行初始化（例如，加载数据、连接数据库、预热缓存）才能处理请求的情况。
Spring Boot Actuator通过/actuator/health/liveness和/actuator/health/readiness等端点，为Kubernetes提供了标准的健康检查接口。当应用程序完全启动并准备就绪时，这些端点会返回200 OK状态码。
问题诊断：过早的探针失败
当Spring Boot应用在Kubernetes中启动后立即关闭时，查看应用日志会发现类似以下的关键信息：
2022-11-30 14:45:14.420 INFO 1 --- [ main] c.a.f.MyApplication : Started FMyApplication in 98.611 seconds (JVM running for 107.522) 2022-11-30 14:45:14.512 DEBUG 1 --- [ionShutdownHook] o.s.b.a.ApplicationAvailabilityBean : Application availability state ReadinessState changed to REFUSING_TRAFFIC ... 2022-11-30 14:45:14.904 INFO 1 --- [ionShutdownHook] j.LocalContainerEntityManagerFactoryBean : Closing JPA EntityManagerFactory for persistence unit 'default'
从日志中可以看出，应用程序报告自身“Started”（启动成功），但紧接着ReadinessState迅速变为REFUSING_TRAFFIC（拒绝流量），随后Spring上下文开始关闭，EntityManagerFactory和数据库连接池也随之关闭。这表明在应用报告启动完成之后，Kubernetes的Readiness探针可能立即执行并失败，导致Kubernetes认为Pod不健康而触发关闭操作。
根本原因在于，Spring Boot应用程序在报告“Started”后，可能还需要一些时间才能完全初始化所有组件并准备好响应外部请求。例如，数据库连接池的初始化、JPA EntityManagerFactory的完全就绪等都需要额外的时间。如果Kubernetes探针在这些组件完全就绪之前就开始检查，就会导致探针失败。
解决方案：配置探针的初始延迟
为了解决这个问题，我们需要在Kubernetes的Pod定义中为Liveness和Readiness探针配置initialDelaySeconds参数。initialDelaySeconds指定了容器启动后，Kubernetes应该等待多少秒才开始执行探针。这为应用程序提供了必要的缓冲时间，使其能够完成所有初始化任务。
推荐配置方式：在Kubernetes部署文件中设置
在Kubernetes的Deployment、StatefulSet或Pod定义中，为容器的livenessProbe和readinessProbe添加initialDelaySeconds。
以下是一个示例Kubernetes Deployment配置片段：
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-spring-app
spec:
replicas: 1
selector:
matchLabels:
app: my-spring-app
template:
metadata:
labels:
app: my-spring-app
spec:
containers:
- name: my-spring-app-container
image: your-repo/my-spring-app:latest
ports:
- containerPort: 8080
livenessProbe:
httpGet:
path: /actuator/health/liveness
port: 8080
initialDelaySeconds: 60 # 容器启动后等待60秒才开始检查存活
periodSeconds: 30 # 每30秒检查一次
timeoutSeconds: 5 # 5秒内无响应则认为失败
failureThreshold: 3 # 连续3次失败则重启容器
readinessProbe:
httpGet:
path: /actuator/health/readiness
port: 8080
initialDelaySeconds: 60 # 容器启动后等待60秒才开始检查就绪
periodSeconds: 30 # 每30秒检查一次
timeoutSeconds: 5 # 5秒内无响应则认为失败
failureThreshold: 3 # 连续3次失败则认为不就绪，停止发送流量在kustomization.yml中，可以通过patches或patchesStrategicMerge来修改现有Deployment的探针配置：
# kustomization.yml 示例
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- deployment.yaml # 假设你的Deployment定义在此文件
patches:
- target:
kind: Deployment
name: my-spring-app
patch: |-
- op: replace
path: /spec/template/spec/containers/0/livenessProbe/initialDelaySeconds
value: 60
- op: replace
path: /spec/template/spec/containers/0/readinessProbe/initialDelaySeconds
value: 60注意事项：
initialDelaySeconds的值：应根据应用程序实际的启动时间来确定。可以通过观察应用程序在问题环境中的完整启动日志（从容器启动到/actuator/health/readiness返回200 OK）来估算所需时间。通常，可以从一个相对保守的值（如30-60秒）开始，然后根据实际情况进行调整。
Liveness和Readiness探针的路径：Spring Boot 2.3及更高版本默认提供了/actuator/health/liveness和/actuator/health/readiness用于区分存活和就绪状态。
periodSeconds、timeoutSeconds、failureThreshold：这些参数也应根据应用的响应特性和可接受的故障容忍度进行合理配置。
-
应用内配置（可选）：虽然Kubernetes的探针配置是首选，但Spring Boot也允许在application.yml中配置Actuator探针的某些行为，例如：
management: endpoint: health: probes: enabled: true livenessProbe: httpGet: path: /actuator/health/liveness port: 8080 initialDelaySeconds: 30 # 此处的initialDelaySeconds仅影响Spring Boot内部的探针行为，不直接控制Kubernetes探针 periodSeconds: 30请注意，application.yml中的initialDelaySeconds主要是为那些不使用Kubernetes但需要内部健康检查的场景设计的，它并不能直接替代Kubernetes Pod定义中的探针配置。Kubernetes的探针配置是最终生效的。
总结
Spring Boot应用在Kubernetes中启动后立即关闭的问题，通常是由于Kubernetes的Liveness和Readiness探针在应用尚未完全准备好时就进行检查并失败所致。通过在Kubernetes的部署配置中，为Liveness和Readiness探针设置合适的initialDelaySeconds，可以为应用程序提供足够的启动和初始化时间。这确保了Kubernetes在应用程序真正健康并准备好接收流量之后才开始对其进行检查，从而避免了不必要的容器重启，提高了应用的稳定性和可用性。在生产环境中部署Spring Boot应用时，合理配置健康探针是保障服务高可用的关键一环。
