Health Checks
Learn how Kubernets checks the application health, and how to use liveness probes and readiness probes.
This section continues from the previous section - make sure you do the tutorial in sequence.
ServiceSpring Boot Actuator
Spring Boot Actuator can provide some basic health checking mechanisms via the /actuator/health
endpoint. However, which endpoint you use depends on the Spring Boot version.
Spring Boot 2.3 and above, Spring Boot Actuator has dedicated support for Liveness Probe.
Spring Boot < 2.3 and below, it's best to create a simple endpoint that simply returns HTTP 200
response status instead of using the Spring Boot Actuator's /actuator/health
endpoint. This is because /actuator/health
by default may fail if an external dependency fails.
Spring Boot Version
Liveness Probe
Readiness Probe
>= 2.3
/actuator/health/liveness
/actuator/health/readiness
< 2.3
Any endpoint that simply returns 200
/actuator/health
Clone
git clone https://github.com/saturnism/jvm-helloworld-by-example
cd jvm-helloworld-by-example/helloworld-springboot-tomcat
Add Dependencies
<project>
...
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
...
</dependencies>
...
</project>
Build
./mvnw package
Containerize
Use Jib to containerize the application:
PROJECT_ID=$(gcloud config get-value project)
./mvnw compile com.google.cloud.tools:jib-maven-plugin:2.4.0:build \
-Dimage=gcr.io/${PROJECT_ID}/helloworld
Liveness Probe
Kubernetes can automatically detect application issues using a Liveness Probe. When the Liveness Probe check fails, Kubernetes will automatically restart the container, in case restarting your application helps it to recover. If the container continues to fail the Liveness Probe, Kubernetes will go into a Crash Loop and backs off the restart exponentially.
If your Liveness Probe checks an endpoint that fails due to an external dependency, but the external dependency cannot recover simply because your container restarts, then it's not a good check! This type of checks may cause catastropic cascading failures.
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: helloworld
name: helloworld
spec:
replicas: 1
selector:
matchLabels:
app: helloworld
template:
metadata:
labels:
app: helloworld
spec:
containers:
- image: gcr.io/.../helloworld
name: helloworld
resources:
requests:
cpu: 200m
memory: 256Mi
limits:
cpu: 500m
memory: 256Mi
# Configure the liveness probe
livenessProbe:
httpGet:
path: /actuator/health/liveness
port: 8080
initialDelaySeconds: 10
When configuring a livenessProbe
, always consider the initial delay needed for your application.
Readiness Probe
Even if your application is alive, it doesn't mean that it's ready to receive traffic. For example, during the startup, the application is alive, but it needs to pre-load data, or warmup caches, before it's ready to accept traffic. A Readiness Probe will let Kubernetes know when your application is ready to receive traffic, and only then will the instance be enlisted into the load balancer as a backend to serve requests (i.e., a Service's Endpoint).
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: helloworld
name: helloworld
spec:
replicas: 1
selector:
matchLabels:
app: helloworld
template:
metadata:
labels:
app: helloworld
spec:
containers:
- image: gcr.io/.../helloworld
name: helloworld
resources:
requests:
cpu: 200m
memory: 256Mi
limits:
cpu: 500m
memory: 256Mi
livenessProbe:
httpGet:
path: /actuator/health/liveness
port: 8080
# Configure the readiness probe
readinessProbe:
httpGet:
path: /actuator/health/readiness
port: 8080
You should always configure a readinessProbe
. Even if you don't use Spring Boot Actuator, you can point the probe to /
or some endpoint that indicates the traffic is ready serve.
Last updated
Was this helpful?