Configuring readiness, liveness, and startup probes in Kubernetes

Probes allow Kubernetes to determine whether a pod may receive traffic, whether a container must be restarted, and how much time an application has to start. Without properly configured probes, faulty pods may continue receiving traffic or be restarted too early.

In this guide, you create a simple demonstration workload with all three probe types. You then test what happens when a pod is not ready and when the liveness check fails.

When do you use each probe type?

• Readiness: use this for web apps, APIs, and other workloads that receive traffic through a Service.
• Liveness: use this if an application may remain stuck in a failed state and only a restart resolves it.
• Startup: use this for slow applications so that liveness does not fail during initialisation, migrations, or cache warm-up.

Readiness is often less important for queue workers and batch processes than for web apps, but startup and liveness probes remain useful to prevent faulty containers from continuing to run indefinitely.

Create a workload with all three probes

Step 1

Connect to your cluster using kubectl and create a .yaml file (a manifest):

nano probes-demo.yaml

Add the following configuration to the file:

apiVersion: v1
kind: Namespace
metadata:
  name: kb-probe-test
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: probe-demo
  namespace: kb-probe-test
spec:
  replicas: 1
  selector:
    matchLabels:
      app: probe-demo
  template:
    metadata:
      labels:
        app: probe-demo
    spec:
      containers:
        - name: app
          image: busybox:1.36
          command: ["/bin/sh", "-c"]
          args:
            - |
              mkdir -p /www
              echo ok > /www/index.html
              (
                sleep 10
                touch /tmp/started
                sleep 10
                touch /tmp/ready
                touch /tmp/healthy
              ) &
              httpd -f -p 8080 -h /www &
              while true; do
                sleep 1
              done
          ports:
            - containerPort: 8080
          startupProbe:
            exec:
              command: ["sh", "-c", "test -f /tmp/healthy"]
            periodSeconds: 5
            failureThreshold: 12
          readinessProbe:
            exec:
              command: ["sh", "-c", "test -f /tmp/ready"]
            periodSeconds: 5
            failureThreshold: 1
          livenessProbe:
            exec:
              command: ["sh", "-c", "test -f /tmp/healthy"]
            periodSeconds: 5
            failureThreshold: 1
---
apiVersion: v1
kind: Service
metadata:
  name: probe-demo
  namespace: kb-probe-test
spec:
  selector:
    app: probe-demo
  ports:
    - port: 8080
      targetPort: 8080

Save the changes and close the file (ctrl + x > y > enter).

Step 2

Create the Deployment and Service:

kubectl apply -f probes-demo.yaml
kubectl -n kb-probe-test rollout status deploy/probe-demo --timeout=180s

Because the `startupProbe` waits for the same condition as the `livenessProbe`, the application has time to reach a 'healthy' status before Kubernetes considers restarting it.

Step 3

Check that the pod eventually becomes `Ready` and appears as an endpoint of the Service:

kubectl -n kb-probe-test get pods -o wide
kubectl -n kb-probe-test get endpoints probe-demo -o yaml

While the readiness check succeeds, the pod's IP address is listed under `addresses` instead of `notReadyAddresses`.

Simulate a readiness failure

Step 1

Remove the readiness condition from the running pod:

kubectl -n kb-probe-test exec deploy/probe-demo -- rm -f /tmp/ready

Step 2

Check the Service endpoints again after a few seconds:

kubectl -n kb-probe-test get endpoints probe-demo -o yaml

The pod should now appear under `notReadyAddresses`. Kubernetes stops routing traffic to it through the Service, but the container continues to run. This demonstrates the difference between readiness and liveness.

Step 3

Finally, restore the readiness condition:

kubectl -n kb-probe-test exec deploy/probe-demo -- touch /tmp/ready

Simulate a liveness failure

Step 1

Remove the liveness condition:

kubectl -n kb-probe-test exec deploy/probe-demo -- rm -f /tmp/healthy

Step 2

Check whether Kubernetes restarts the container:

kubectl -n kb-probe-test get pod -l app=probe-demo -w --request-timeout=15s

You should see the restart count increase. Kubernetes is recovering a container that is still running but is no longer functioning correctly.

Step 3

Finally, restore the liveness condition:

kubectl -n kb-probe-test exec deploy/probe-demo -- touch /tmp/healthy

A good combination of readiness, liveness, and startup probes prevents two common problems at once: traffic being sent to pods that are not ready and containers that are no longer functioning but do not stop automatically. This makes your cluster more reliable and secure.