Kubernetes Liveness Probes

Kubernetes uses the liveness probes to decide when to restart a container. There are three types of configurations probs for the containers, startup, readiness, and liveness. The startup probe is defined in the Kubernetes environment to tell the cluster when to start a container application. The readiness probe is used by the Kubernetes container to check when it can start accepting traffic. To determine when to restart a container, however, liveness probes are employed. In this guide, we will explore the liveness probe in-depth and learn how and when to use it in the Kubernetes environment.

What is a Liveness Probe in Kubernetes?

A cluster in Kubernetes passes through different stages in its complete lifecycle having different states. These states can be checked by the probes which are the automated process for checking the current state of the cluster. In simple words, the liveness probes are the health checker of the clusters. It is a mechanism provided by Kubernetes that is used to check if the applications are properly running in the container or not.

The liveness probe is used to make sure that an application is properly running in a container and that it is live. These probes are used to know when to restart containers if they are not working or are not in active mode. Any application which is broken, stopped by an error, or transitioned to a broken state, is chosen and can be fixed by restarting the cluster. Nothing else is done if the liveness probe is successful in correcting the application. However, if it fails, then the event log is maintained and kubectl commands are used to kill the container according to the restartPolicy configuration.

How Does a Liveness Probe Work on a Kubernetes Cluster?

A liveness probe is an automated process that is used to check the state of the cluster in the Kubernetes environment. The liveness probe periodically sends an HTTP request or runs a command to an endpoint on a container and waits for the response. In case the container does not respond, returns a failure; or if no response arrives within a specific time frame, the liveness probe restarts the container.

Liveness probes provide granular-level details of whether an application is properly running in a cluster or not. By default, the Kubernetes controller determines whether a pod is running or not. If the pod is not running, then the liveness probes trigger the restart on the pod by following the restart policy of the pod. In some cases, the pods are running properly but the application might have malfunctioned. All these granular details can be checked with the liveness probes.

Let us learn how to define the liveness probe for the cluster in the Kubernetes environment by following the step-by-step guide given below.


Before you learn how to define the liveness probe in the Kubernetes environment, make sure you have a suitable system. Some tools must be properly installed and configured in your Kubernetes environment to define the liveness probe. See the list of tools mentioned here:

    • Ubuntu 22.024or any other latest version
    • Kubectl command line tool
    • Kubernetes cluster
    • Minikube cluster
    • Minimum of two nodes that are not working as control plane host

Once you have these tools configured in your system, you are ready to define a liveness probe for your Kubernetes cluster. Assuming that your system is prepared and ready to work, we are moving to the next section.

How to Define a Liveness Probe for the Kubernetes Cluster?

Some of the applications run in the Kubernetes cluster for a long period and eventually transition to a broken or failed state. These states are stubborn enough that cannot be resolved without restarting the container in which they are running. The liveness probes are defined to detect such states and schedule a restart for the cluster whenever required. So, here, we are going to teach you how to define a liveness probe for the Kubernetes cluster.

Step # 1: Start the Minikube Cluster

First, you need to start your minikube cluster to make sure that it is up and running properly. The cluster can be started by using the command given below:

> minikube start


Step # 2: Create a Pod

We have a YAML configuration file that we will be using to create a pod in the container. The configuration file contains the deployment definition for the pod. Use your command line tool to run the following command to deploy the pod in the Kubernetes cluster:

> kubectl apply -f https://k8s.io/examples/pods/probe/exec-liveness.yaml


From the output given above, you can notice that the pod named ‘liveness-exec’ has been created from the YAML configuration file. Now, we will apply the liveness probes on the pod so that whenever the pods get in inactive mode, it gets restarted with the liveness probe.

Step # 3: View Pod Events

Now, let us check the events log of the pod which we have created in the previous step to check how a liveness probe is working on this pod. To check the pod’s events, we will use the following command:

> kubectl describe pod liveness-exec


From the output given above, you can see that the liveness probe runs on the pod after every 5 seconds to check if it is still active or not. You can also notice that the liveness probe is successful once and failed three times. If the liveness probe keeps on getting failed, the container will be killed and recreated.

Step # 4: Verify the Container is Restarted

Since the liveness probe has failed three times, let us verify if the pod has restarted again by the liveness prob or not. By using the following command, we may determine the status of the pod:

> kubectl get pod liveness-exec



We explore the Kubernetes probes defined for containers. There are three types of probes defined for the containers in the Kubernetes environment: liveness, startup, and readiness. This document was focused on the liveness probe which is used to restart the cluster whenever required. The liveness probe is a health checker which makes sure that a cluster is up and running properly.

About the author

Kalsoom Bibi

Hello, I am a freelance writer and usually write for Linux and other technology related content