Kubernetes health checks with liveness, readiness, and startup probes

• Author
• Recent Posts

Avi

Avi is a tech enthusiast with expertise in trending technologies, such as DevOps, cloud computing, and big data. He is passionate about learning cutting-edge technologies and sharing his knowledge with others.

Latest posts by Avi (see all)

• Create a Kubernetes Helm Chart with example - Wed, Sep 27 2023
• Create your first Grafana dashboard - Mon, Sep 18 2023
• Kubernetes resource requests, resource limits, and LimitRanges - Fri, Sep 15 2023

Kubernetes uses different probes to check the health of containers at different stages in their life cycles. Below are the three probe types used by Kubernetes:

• Liveness probes check whether a container app is responding to requests. Kubernetes uses liveness probes to determine when to restart a container.
• Readiness probes determine whether a container can receive traffic. These probes can be used to delay sending traffic to a new instance until an application has completed tasks.
• Startup probes detect when an application inside a container finishes its initialization. Kubernetes can identify slow-starting apps using the startup probe and not kill them due to the delay.

Now that you know the basics of probes in Kubernetes, let's look at the steps to configure them one by one.

Liveness probe

You can define a liveness probe for Kubernetes deployments and pods.

Here, we create a liveness probe example for a pod. Our pod, named liveness-probe, will check the health of a container of an echoserver image every 10 seconds, with an initial delay of 30 seconds. The echoserver is a simple application often used in Kubernetes to demonstrate or test networking concepts.

We will use an HTTP handler to send a GET request to check whether the health path is accessible at port 8080. If not, Kubernetes marks the container as unhealthy and restarts it. /health is an HTTP endpoint that is used in Kubernetes probes to get the health status of the application running inside the container. Kubernetes periodically sends HTTP requests to the /health endpoint to check the health status.

First, we will create a yaml file for the container for the echoserver app with the liveness probe, as shown below.

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-probe
spec:
  containers:
        - name: liveness-probe
          image: gcr.io/google_containers/echoserver:1.4
          livenessProbe:
            httpGet:
              path: /health
              port: 8080
              scheme: HTTP
            timeoutSeconds: 10
            periodSeconds: 10
            initialDelaySeconds: 30

These are the meaning of the crucial parameters:

path: /health is the endpoint at which Kubernetes will send HTTP GET requests to check the liveness of the container. /health is not a keyword in Kubernetes; it is the URL of the NGINX web server used for health checks.

timeoutSeconds defines the wait time duration (in seconds), after which the probe will time out. By default, it is set to 1 second.

periodSeconds specifies how often to perform the probe. The default is 10 seconds. The minimum value is 1.

initialDelaySeconds is the time difference between the start of the container and a probe launch to allow the application to initialize. By default, it is set to 0 seconds.

In addition, you can work these parameters:

successThreshold specifies the minimum consecutive successes for the probe to be considered successful after having failed. By default, it is set to 1.

failureThreshold determines the number of times the probe should fail before the Kubernetes considers the probe as failed. By default, it is set to 3.

Next, we apply the liveness.yaml configuration file using the kubectl command. This will create the pod in the Kubernetes cluster.

kubectl apply -f /home/osboxes/liveness.yaml

Create the liveness probe

We will now check whether the pod started successfully and is running.

kubectl get pods

Check liveness probe pod status

Finally, we will run kubectl describe pod to get detailed information on the liveness-probe pod.

kubectl describe pod liveness-probe

Describe liveness probe pod

If you scroll down to Events, you can see that the liveness-probe container was created and started.

Liveness probe health check

By default, the container host port of echoserver is accessible at 8080. I will now change the port to 80 in a new liveness-probe, and create a new pod, called liveness-probe-new:

Create a yaml file for the container with the new liveness probe, as shown below.

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-probe-new
spec:
  containers:
        - name: liveness-probe-new
          image: gcr.io/google_containers/echoserver:1.4
          livenessProbe:
            httpGet:
              path: /health
              port: 80
              scheme: HTTP
            timeoutSeconds: 10
            periodSeconds: 10
            initialDelaySeconds: 30

Next, we apply the liveness-probe-new.yaml configuration file using the kubectl command. This will create the pod in the Kubernetes cluster.

kubectl apply -f /home/osboxes/liveness-probe-new.yaml

Create a new liveness probe

If we check the status of the pod, we can see the probe is not able to access the /health path at port 80 and hence the pod is crashing.

kubectl get pods

Check liveness probe new pod status

Run kubectl to describe the pod to get detailed information on the liveness-probe-new pod.

kubectl describe pod liveness-probe-new

Describe liveness probe new pod

In the output below, we can see that the liveness probe fails, and the status becomes unhealthy. So, the container is killed and restarted by a liveness probe.

Liveness probe new health check

Next, let's see how to configure the readiness probe in Kubernetes.

Readiness probe

Next, we create a readiness probe. Our pod, named readiness-probe, checks the root path of the nginx container every 10 seconds with an initial delay of 30 seconds. We should get a success message at least once to consider the readiness probe successful.

We will use an HTTP handler to send a get request to check whether the root path of the NGINX web server is accessible. If it is not accessible, Kubernetes will consider the container unhealthy, and it will stop sending traffic to the container.

First, we will create a YAML file for the readiness probe, as shown below. Create a readiness.yaml file, and add the configurations described below.

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: readiness
  name: readiness-probe
spec:
      containers:
        - name: readiness-probe
          image: nginx
          readinessProbe:
            httpGet:
               path: /
               port: 80
            successThreshold: 1
            periodSeconds: 10
            initialDelaySeconds: 30

Apply the readiness.yaml configuration file using the kubectl command. This will create the pod in the Kubernetes cluster, and the command should return a message that the probe was created.

kubectl apply -f /home/osboxes/readiness.yaml

Create a readiness probe

Check whether the readiness-probe pod is running or not.

kubectl get pods

Check readiness probe pod status

Use kubectl describe pod to get detailed information on the readiness-probe pod.

kubectl describe pod readiness-probe

Describe readiness probe pod

We can see that the nginx container was pulled and created, and Kubernetes can send traffic to it. Here, "pulling image "nginx"" means fetching the NGINX container image from a Docker registry. Once the image is pulled, Kubernetes uses it to create the NGINX container and launch it as a pod.

Readiness probe health check

Finally, let's see how to configure the startup probe in Kubernetes.

Startup probe

In this example, we will create a pod named startup-probe and then configure a startup probe that checks the root path of the nginx container every 10 seconds, with an initial delay of 30 seconds.

We will use the HTTP handler to send a GET request to check whether the root path is accessible. If not, Kubernetes will wait for the startup probe to finish until it sends traffic to the container.

First, we will create a YAML file for the startup probe container, as shown below. Create a startup.yaml file and add the configurations described below.

onfigurations described below.
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: startup
  name: startup-probe
spec:
      containers:
        - name: startup-probe
          image: nginx
          startupProbe:
            httpGet:
               path: /
               port: 80
            periodSeconds: 10
            initialDelaySeconds: 30

Apply the startup.yaml configuration file using the kubectl command. This will create the pod in the Kubernetes cluster, and the command should return a message that the probe was created.

kubectl apply -f /home/osboxes/startup.yaml

Create a startup probe

Check whether the startup-probe pod is running.

kubectl get pods

Check startup probe pod status

Use kubectl describe pod to get detailed information on the startup-probe pod.

kubectl describe pod startup-probe

Describe startup probe pod

We can see that the nginx container was pulled, created, and started successfully. So, now Kubernetes can send traffic to the nginx container.

Startup probe health check

Conclusion

In a Kubernetes cluster, probes are crucial to ensure the container's health. In this article, you learned how to configure readiness, liveness, and startup probes. Feel free to ask questions in the comment section below.