How to use a liveness probe for applications on Kubernetes?

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

view raw liveness-exec.yaml hosted with ❤ by GitHub

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

view raw liveness-http.yaml hosted with ❤ by GitHub

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

view raw liveness-tcp.yaml hosted with ❤ by GitHub

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.