Liveness & Readiness Probes
Probes let Kubernetes check container health to restart the stuck and route traffic only to the ready.
Kubernetes can't know if your app is truly healthy just because the process is alive. Probes are periodic health checks that tell it what to do.
The three probes
- livenessProbe — is the app alive? If it fails, Kubernetes restarts the container. Fixes deadlocks and hangs.
- readinessProbe — is the app ready for traffic? If it fails, the Pod is removed from Service endpoints (no restart). Great during startup or temporary overload.
- startupProbe — protects slow-starting apps by delaying the other probes until the app has booted.
Check methods
Each probe can use an HTTP GET, a TCP socket connection, or running a command (exec) inside the container.
Example
apiVersion: v1
kind: Pod
metadata:
name: probed-app
spec:
containers:
- name: app
image: myapp:1.0
ports:
- containerPort: 8080
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 10
periodSeconds: 10
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 5When to use it
- A REST API uses a readinessProbe on its /health endpoint so that pods receive no traffic until the application has finished loading its configuration.
- A long-running worker uses a livenessProbe so that Kubernetes automatically restarts it if it gets stuck in a deadlock without crashing.
- A slow-starting JVM service sets an initialDelaySeconds of 60 on its liveness probe to avoid premature restarts during the JVM warm-up phase.
More examples
HTTP liveness and readiness probes
Configures a liveness probe that restarts the pod after 3 consecutive failures, and a readiness probe that removes it from service until /ready returns 200.
spec:
containers:
- name: api
image: myapi:1.0
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 15
periodSeconds: 10
failureThreshold: 3
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 5Exec probe for non-HTTP services
Uses a shell command (redis-cli ping) as a liveness probe for a Redis container that does not expose an HTTP endpoint.
livenessProbe:
exec:
command:
- /bin/sh
- -c
- redis-cli ping | grep PONG
initialDelaySeconds: 10
periodSeconds: 15Startup probe for slow JVM
Adds a startupProbe that gives a Spring Boot app up to 300 seconds to start before liveness checks begin.
startupProbe:
httpGet:
path: /actuator/health
port: 8080
failureThreshold: 30
periodSeconds: 10
# Allows up to 300 seconds for JVM startup
# Liveness probe only activates after startup probe succeeds
Discussion