Liveness and Readiness Probes with Spring Boot
SpringBoot is the most used framework for creating micro-service based services nowadays. Spring Boot is actively working on providing features that will work for Kubernetes.
After docker creation using the Spring boot maven plugin, they added the support for Graceful Shutdown support. In the recent version of Spring Boot, it is supporting for liveness and readiness probes support.
Spring boot 2.2.0 release version introduced the new health group configuration, where we can separate the health endpoints into a different group, one can be used for Liveness and one can use for readiness probes.
Liveness:
The Liveness state of an application will inform the Kubernetes control panel, that pod is an active state to accept the requests from the user. If the Liveness of the application is broken, it means the application went to a failed state, which can’t recover from it. We need to restart the application instance to back into the active state. For suppose if the application is using cache for different purposes, if this cache is corrupted then the application will not behave like previous, the best possible solution will be restarting the application, as it is not repaired any case.
Readiness:
Readiness tells the Kubernetes control-panel that the application is ready to accept the incoming request or not. Some applications will take some time to start in running mode, meanwhile, if a request comes up, they will not be able to accept or process the request. One more possible use-case for readiness will be if the application processing some complex computations and most of the resources allocated to this computation, and it not able to accept the new request then also pod needs to inform the Kubernetes control-panel that application will not allow accepting the requests.
Liveness and Readiness in spring-boot:
This liveness and readiness are not specific to Kubernetes, which are generally useful in all deployment platforms like Java application development, and also if this producing the Service, the client will check for application status whether it will accept the request form client or not.
In the recent versions of spring-boot, they introduce the new classes, LivenessState and ReadinessState, which are immutable representations of those concepts.
We get these states from ApplicationAvailabilityProvider class at any time.
ApplicationAvailabilityProvider availabilityProvider= …
LivenessState livenessState = availabilityProvider.getLivenessState();
ReadinessState readinessState = availabilityProvider.getReadinessState();
A polling-only model is used to find the status of the application.
A LivenessStateChangedEvent is sent right after to indicate that the application is considered as live. And our application code also has contributed to updating this status.
If the application is facing any of the critical problems, then the application code should raise the LivenessStateChangedEvent state event with the proper message so that we can easily get to know what kind of the problem the application has, based on this we can decide it is recoverable problem, or not.
And this event we can subscribe like the previous way either by implementing ApplicationListener<LivenessStateChangedEvent> or annotation method with @EventListener.
A ReadinessStateChangedEvent is sent right after to indicate that the application is ready to service requests.
Exposing Liveness and Readiness probes with Kubernetes:
Spring-boot-actuator is the dependency where all these health indicator endpoints are producing. So we need to spring-boot-actuator dependency for this requirement, By default all these health endpoints are disabled, we need to enable this endpoint using below configuration property.
management.health.probes.enabled=true
For Liveness and Readiness spring-boot-actuator provides two different health indicators LivenessProbeHealthIndicator and ReadinessProbeHealthIndicator.
Spring-Boot-Actuator will collect health information from these indicators at all times using the Application Evolution Provider.
By default two heal groups are provided by spring-boot-actuator, we can get the same by invoking /actuator/health endpoint on our application.
{
“status”: “UP”,
“components”: {
“diskSpace”: {
“status”: “UP”,
“details”: { //…
}
},
“livenessProbe”: {
“status”: “UP”
},
“ping”: {
“status”: “UP”
},
“readinessProbe”: {
“status”: “UP”
}
},
“groups”: [
“liveness”,
“readiness”
]
}
we can get the each probe information using/actuator/health/liveness and /actuator/health/readiness endpoints.
Sample response for success Liveness:
{
“status”: “UP”,
“components”: {
“livenessProbe”: {
“status”: “UP”
}
}
}
Sample successful response for readiness:
{
“status”: “READY”,
“components”: {
“readinessProbe”: {
“status”: “READY”
}
}
}
And add this configuration in application pod YAML file:
livenessProbe:
httpGet:
path: /actuator/health/liveness
port: 8080
initialDelaySeconds: 10
periodSeconds: 3
readinessProbe:
httpGet:
path: actuator/health/readiness
port: 8080
initialDelaySeconds: 20
periodSeconds: 10
Conclusion:
In this Article, the Java Development Company explains the Kubernetes liveness and readiness probes, and also spring boot-actuator endpoints used for configuring the probes in YAML files.
