Search code examples
spring-bootkubernetesspring-boot-actuatorreadinessprobelivenessprobe

Using /actuator/health when Spring application is deployed on k8s?


I wonder what the drawbacks of the Spring Boot application are that it has a /health actuator endpoint defined as liveness and readiness probes.

Are there any issues related to graceful shutdown or rolling updates?


Solution

  • Interesting question. I found this answer on Reddit.

    Here is the big one that most people miss, though. Handling of SIGTERM events is a must in Kubernetes. Evictions, pod autoscalers, and just regular operation (like kubectl apply ...) can lead to pods getting killed prematurely. This happens by sending a SIGTERM event to the application. The readiness probe MUST respond differently than a liveness probe after the SIGTERM event has been received but before the app is able to exit. The readiness probe must return failure, while the liveness probe must return success. In this way, no new requests are sent to the terminated replica, but existing requests that are currently being processed are able to complete. After the liveness probe returns failure, Kubernetes may send a SIGKILL event, terminating your app immediately. In order for this to be handled properly, your liveness probe MUST remain healthy and your readiness probe MUST return failure. Of course, after the request in flight have been completed, your liveness probe should return failure, but only after all requests in flight have been completed.