While Readiness Probes check the application running inside the container for readiness, Liveness Probes check the application running inside the container periodically to check if the application is healthy (live). If the application becomes unhealthy, the pod gets restarted.
Without liveness probes, the application could be stuck in an infinite loop or frozen while the status of the pod is running, making us believe that the application is working fine. In this case, the pod will not be restarted.
<aside>
💡 Liveness probes are configured just like Readiness probes, we just use livenessProbe
instead of readinessProbe
in the pod definition.
</aside>
This is commonly used for containers hosting web applications. The application exposes an HTTP health check endpoint. Only if the endpoint returns a 200 status code, the container will be considered live.
apiVersion: v1
kind: Pod
metadata:
labels:
name: frontend
spec:
containers:
- name: webapp
image: webapp
ports:
- containerPort: 8080
livenessProbe:
httpGet:
path: /api/ready
port: 8080
This is commonly used for containers hosting databases. The container’s TCP port on which the DB is exposed is checked for liveness.
apiVersion: v1
kind: Pod
metadata:
labels:
name: database
spec:
containers:
- name: database
image: database
ports:
- containerPort: 3306
livenessProbe:
tcpSocket:
port: 3306
Run a shell script inside the container to check the liveness of the application. The return code of the shell script is used to determine the liveness of the container.
apiVersion: v1
kind: Pod
metadata:
labels:
name: app
spec:
containers:
- name: app
image: app
livenessProbe:
exec:
command:
- cat
- /app/ready
livenessProbe:
httpGet:
path: /api/ready
port: 8080
initialDelaySeconds: 10
periodSeconds: 5
failureThreshold: 5
initialDelaySeconds
- start checking for liveness after some delay
periodSeconds
- liveness check interval
failureThreshold
- how many times to check for liveness before declaring the status of container to failed and restart the container (default 3)