Kubernetes Health Check Tutorial: Configure Liveness and Readiness Probes 💎

The fourth CKAD mock exam question and answer covers Kubernetes health check probes (k8s health check probes) including liveness probes and readiness probes (startup probes excluded), in this Kubernetes (k8s) practice exam series.

The following is taken from the Practice Exam for Certified Kubernetes Application Developer (CKAD) Certification on Matthew Palmer’s website and reads as follows:

All operations in this question should be performed in the ggckad-s4 namespace.

This question will require you to create a pod that runs the image kubegoldenguide/question-thirteen.

This image is in the main Docker repository at hub.docker.com.

This image is a web server that has a health endpoint served at ‘/health’.

The web server listens on port 8000. (It runs Python’s SimpleHTTPServer.)

It returns a 200 status code response when the application is healthy.

The application typically takes sixty seconds to start.

Create a pod called question-13-pod to run this application, making sure to define liveness and readiness probes that use this health endpoint.

Unlike previous questions, this one specifically tells us that the kubegoldenguide/question-thirteen image is in the main Docker repository at hub.docker.com.

According to the Kubernetes Images:Image Names documentation, “[i]f you don’t specify a registry hostname, Kubernetes assumes that you mean the Docker public registry” so no further action should be necessary with respect to this detail.

This article was last updated on June 17, 2025.

Kubernetes Health Check Icons

Explore visual icons illustrating key aspects of Kubernetes health check probes, available in SVG and PNG formats.

Kubernetes Liveness and Readiness Probe Icon

An SVG icon representing a Kubernetes liveness and readiness probe — symbolized by a heart with a check mark, available in:

Kubernetes Liveness Probe Icon

An SVG icon representing a Kubernetes liveness probe — symbolized by a heart with a with a heartbeat monitor graph, available in:

Kubernetes Readiness Probe Icon

An SVG icon representing a Kubernetes readiness probe — symbolized by a checkbox with checkmark applied, available in:

Kubernetes Health Check Probe Icon

An SVG icon representing a Kubernetes health check probe — symbolized by a doctor’s stethoscope and also available in PNG format as follows:

Feel free to reference or share these images and note that they have been released under the Creative Commons Attribution 4.0 license.

Learn how to add Kubernetes health check probes to your pod configuration file.

In this section we’ll discuss the steps required to add a liveness probe and readiness probe to our k8s pod configuration file and then we’ll test our changes.

K8s Health Check Article Prerequisites

Refer to the article prerequisites for details about technology and setup instructions required to answer this question.

As per the instructions, we also need to create the ggckad-s4 namespace, and we can achieve this with the following command:

				
					kubectl create namespace ggckad-s4

I’ve included an example of the successful execution of the command below.

Once you’ve created the ggckad-s4 namespace we can then move on to step one of this exercise.

Step One: Generate a basic pod configuration file from the kubegoldenguide/question-thirteen Docker image.

In the first step we’ll generate a pod configuration file.

Keep in mind that we have a specific namespace requirement listed in the instructions, and this is included in the command below.

				
					kubectl run question-13-pod --image=kubegoldenguide/question-thirteen --namespace=ggckad-s4 --dry-run=client -o yaml > question-four.yaml

This command should return successfully as the example below demonstrates.

The red underline in the image below points to the kubegoldenguide/question-thirteen and the orange underline captures the ggckad-s4 namespace requirement.

We can see the contents of this file in the following image — note that this is pretty basic, and doesn’t include any liveness or rediness probes yet — we’ll add these ourselves.

Same as above, the red underline in the image below points to the kubegoldenguide/question-thirteen and the orange underline captures the ggckad-s4 namespace requirement.

I’ve copied the contents of the question-four.yaml file below as we’re going to need to edit this and add our liveness and readiness probes.

				
					apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: question-13-pod
  name: question-13-pod
  namespace: ggckad-s4
spec:
  containers:
  - image: kubegoldenguide/question-thirteen
    name: question-13-pod
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

In the next step we’ll add a Kubernetes liveness probe.

Step Two: Add a liveness probe to the k8s pod configuration file.

In the second step we’ll add a liveness probe to the Kubernetes pod configuration file.

The instructions mention that the application takes 60 seconds to start so the initial delay has been set to 75 seconds to account for the possibility that this number might fluctuate a bit; the period and timeout seconds have been set to five and ten seconds respectively.

According to the section entitled Define a liveness HTTP request, “[a]ny code greater than or equal to 200 and less than 400 indicates success.” — so no action is required in our solution as the server running in the question-thirteen container will return an HTTP status response code of 200 when the application is healthy.

				
					apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: question-13-pod
  name: question-13-pod
  namespace: ggckad-s4
spec:
  containers:
  - image: kubegoldenguide/question-thirteen
    name: question-13-pod
    resources: {}
    livenessProbe:
        httpGet:
          path: /health
          port: 8000
        initialDelaySeconds: 75
        periodSeconds: 10
        timeoutSeconds: 5
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

Step Three (optional): Testing the liveness probe.

Developing a test that shows that the liveness probe is configured properly is not exactly straightforward and I’ll explain why in a moment.

We need to check the k8s logs for the question-13-pod pod in the ggchad-s4 namespace — we can do this with the following command:

				
					kubectl logs question-13-pod --namespace ggckad-s4 --v=6

If we configured the liveness probe as instructed in step one, the logs should look something like the image below.

Keep in mind that the liveness probe has an initial delay of 75 seconds so these log entries will not appear immediately on startup.

The issue here is that nothing specifically indicates that these log entries relate to the liveness probe.

If we want to prove that the liveness probe is running correctly, we can deliberately misconfigure it and see if the log events change.

In the example below the livenessProbe path is set to “/healthy”, which is incorrect.

Once we’ve applied the changes for the question-13-pod pod, we can check the logs again and see if there’s a problem.

In the image below we can see that we now have HTTP 404 status codes appearing in the log for the /healthy path.

This suggests that our livenessProbe is configured correctly, we should see the HTTP 200 status code in the k8s logs as was demonstrated earlier in this document.

There may be a better way of achieving the same result — if you know of one add it in the comments.

See the StackOverflow question entitled Kubernetes Liveness Probe Logging for conversation about this specific query.

Step Four: Add a readiness probe to the k8s pod configuration file.

In step four we add a readiness probe to the question-13-pod k8s pod configuration file.

This step is performed in isolation from step two so we can also test this in isolation as well.

The correct readinessProbe configuration appears in lines #14 to #19 below and uses the same endpoint path that the k8s livenessProbe relies on.

				
					apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: question-13-pod
  name: question-13-pod
  namespace: ggckad-s4
spec:
  containers:
  - image: kubegoldenguide/question-thirteen
    name: question-13-pod
    resources: {}
    readinessProbe:
        httpGet:
          path: /health
          port: 8000
        initialDelaySeconds: 60
        periodSeconds: 5
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

NOTE: that I have the initialDelaySeconds set to 60 in this example, and this may be a bit confusing because in step #2 the livenessProbe initialDelaySeconds was set to 75 as a way of accounting for the possibility that the pod may take slightly longer than one minute to start.

The result is that it may make sense to change this number to 75, but for now this is working and won’t be changed.

Step Five (optional): Testing the readiness probe.

Testing the readinessProbe configuration is performed exactly the same as we’ve done in step three and will not be covered here.

Note that to be clear, the log file output when testing the readinessProbe is exactly the same as is demonstrated in step three for both successful as well as unsuccessful scenarios.

Step Six: Add a liveness and readiness probe to the k8s pod configuration file.

This section includes the correct and fully-working example of a pod configuration which uses the correct Kubernetes namespace and contains both liveness probes and readyness probes.

See lines #8 and #14 through #26 below.

				
					apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: question-13-pod
  name: question-13-pod
  namespace: ggckad-s4
spec:
  containers:
  - image: kubegoldenguide/question-thirteen
    name: question-13-pod
    resources: {}
    livenessProbe:
        httpGet:
          path: /health
          port: 8000
        initialDelaySeconds: 75
        periodSeconds: 10
        timeoutSeconds: 5
    readinessProbe:
        httpGet:
          path: /health
          port: 8000
        initialDelaySeconds: 60
        periodSeconds: 5
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

In the next step we’ll explore the output for the complete solution all the way from namespace creation to checking the Kubernetes logs for our specific pod.

Step Seven: Apply the pod configuration file and check the log events.

In this step we can see a full working example from start to finish — see the image below for full output details and the explanation for each pointer follows.

The breakdown of each step is as follows:

The Yellow pointer points to the ggckad-s4 namespace creation (“kubectl create namespace ggckad-s4”).
The orange pointer directs our attention to the livenessProbe configuration.
The red pointer directs our attention to the readinessProbe configuration.
The blue pointer directs our attention to the line where we apply the pod configuration file (“date && kubectl apply -f question-four.yaml”).
After waiting for a few minutes we check the k8s logs — refer to the green pointer.
Finally, the magenta pointer points to get events on the /health endpoint that have returned HTTP status code 200, which indicates that the call returned successfully.

This concludes this section — the tutorial conclusion follows.

Kubernetes Health Check Tutorial Conclusion

I hope this instructional has been helpful in understanding how to configure liveness and readiness probes in Kubernetes.

The startup, readiness, and liveness probes are part of the Kubernetes health check mechanisms that ensure containers are running correctly, accepting traffic, and able to recover from failure, thereby maintaining an application’s reliability and stability.

Finally, The k8s health check probes are crucial for automating the management of containerized applications, and ensure that they operate as expected and without the need for manual intervention.

Kubernetes Health Check FAQ

What are health check probes in Kubernetes?

Health check probes in Kubernetes are automated checks that monitor the status of a container.

Kubernetes uses three types of probes: liveness probes, readiness probes, and startup probes.

The Kubernetes health check probes ensure that containers have started successfully, are running properly, and are ready to accept traffic.

These probes help to maintain application stability by automatically restarting containers or removing them from service if needed.

What is a liveness probe in Kubernetes?

A liveness probe in Kubernetes is used to monitor if a container is still running properly.

If the liveness probe fails, Kubernetes will attempt to restart the container in order to fix problems such as crashes or deadlocks — this helps to maintain application stability automatically.

What is a readiness probe in Kubernetes?

A Kubernetes readiness probe checks if a container is ready to handle traffic — if the probe fails, k8s excludes the container from the Service’s endpoints, thereby preventing traffic from being routed to the container until the probe succeeds.

This approach ensures reliable and efficient service routing.

Readiness probes are optional and configured per container.

ThosPFuller

I am a software engineer based in Northern Virginia (USA) and this website focuses on content engineering, web development, Technical SEO, Search Engine Optimization (SEO).

See Full Bio