Trusted answers to developer questions

How to use a liveness probe for applications on Kubernetes?

Get the Learn to Code Starter Pack

Break into tech with the logic & computer science skills you’d learn in a bootcamp or university — at a fraction of the cost. Educative's hand-on curriculum is perfect for new learners hoping to launch a career.

What is a liveness probe?

Liveness probes are used by the kubelet (kubernetes agent) to identify when to restart a container. The kubelet can identify a pod crash and restart the pod in such an event. However, at times, it may happen that the pod is alive but the application is in a state where it cannot serve requests, and restarting the application makes sense.

For example, your application might have gone into a deadlock, and a restart may allow it to recover and start serving the requests again.

How to configure a liveness probe?

Liveness is configured in a pod container spec. You can see an example below.

apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: live-exec
spec:
containers:
- name: liveness
image: k8s.gcr.io/busybox
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5

In the code snippet above, the pod has a single container. Let’s look at what each line does in some detail.

  • Line 15 defines the liveness probe. We are using the exec to indicate that the liveness probe is a command.

  • Line 18 and 19 indicate that the liveness probe will do a cat /tmp/healthy and if the command return zero, we exit the code, and the liveness probe is considered successful.

  • Line 20 gives the value of initialDelaySeconds as 5, which tells Kubernetes to start the liveness probe after 5 seconds elapse from the pod start.

  • Line 21 gives the value of periodSeconds as 5, which tells Kubernetes to do a liveness check every 5 seconds after the first one.

Using an HTTP request for a liveness probe

Let’s look at an example of using an HTTP request for a liveness probe.

apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: live-http
spec:
containers:
- name: liveness
image: k8s.gcr.io/liveness
args:
- /server
livenessProbe:
httpGet:
path: /healthz
port: 8080
httpHeaders:
- name: Custom-Header
value: Awesome
initialDelaySeconds: 3
periodSeconds: 3

In the code snippet above, the pod has a single container. Let’s look at what each line does in some detail.

  • Line 13 defines the liveness probe.
  • We are using the httpGet on line 14 to indicate that the liveness probe is an HTTP get request.
  • Line 15-19 provide the HTTP get request parameters. The liveness probe will succeed if the HTTP request returns 200.
  • Line 20 and 21 indicate the initialDelaySeconds and periodSeconds, both of which have been explained in the previous section.

Using TCP for a liveness probe

Let’s look at an example of using TCP for a liveness probe.

apiVersion: v1
kind: Pod
metadata:
name: goproxy
labels:
app: goproxy
spec:
containers:
- name: goproxy
image: k8s.gcr.io/goproxy:0.1
ports:
- containerPort: 8080
livenessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 15
periodSeconds: 20

In the code snippet above, the pod has a single container. Let’s look at what each line does in some detail.

  • Line 13 defines the liveness probe.
  • We are using the tcpSocket on line 14 to indicate that the liveness probe is a TCP request.
  • Line 15 indicates that the TCP request will be made on port 8080. The liveness probe will succeed if the TCP socket connection to port 8080 succeeds.
  • Line 16 and 17 indicate the initialDelaySeconds and periodSeconds, both of which have been explained in the previous section.

Conclusion

Liveness probes help the kubelet know when to restart your container. There are multiple ways to configure a liveness probe, and the application owner can choose what is best for the application.

RELATED TAGS

kuberenetes
pod
liveness
Did you find this helpful?