Liveness Probes

An application gets into a deadlock. The HTTP server stops responding. The process is still running, so the kubelet does not restart it. Without a liveness probe, the container stays in this broken state until someone notices and manually intervenes. A liveness probe detects this and triggers a restart automatically.

The liveness probe runs repeatedly throughout the container’s lifetime. Each failure increments a counter. When the failure count reaches the failureThreshold, the kubelet kills and restarts the container. A single success resets the counter.

An HTTP liveness probe

The most common probe type for web applications: check a health endpoint and expect a 2xx or 3xx response.

nano liveness-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: liveness-pod
spec:
  containers:
    - name: app
      image: busybox:1.36
      command:
        - sh
        - -c
        - |
          mkdir -p /tmp/health
          echo "OK" > /tmp/health/live
          sleep 3600
      livenessProbe:
        exec:
          command:
            - cat
            - /tmp/health/live
        initialDelaySeconds: 5
        periodSeconds: 10
        failureThreshold: 3

This uses an exec probe (running a command) because busybox does not serve HTTP. In a real application, the httpGet probe type is more common:

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 15
  failureThreshold: 3

kubectl apply -f liveness-pod.yaml
kubectl describe pod liveness-pod

Look at the Liveness line in the container section. It shows the probe configuration and the current success/failure count.

Simulating a liveness failure

Remove the health file to cause the exec probe to fail:

kubectl exec liveness-pod -- rm /tmp/health/live

Wait 30 seconds (3 probe periods), then check:

kubectl get pod liveness-pod
kubectl describe pod liveness-pod

The RESTARTS counter has incremented. The Events section shows Liveness probe failed: ... followed by Killing container with id.... The container was restarted.

After restart, the startup command runs again and recreates /tmp/health/live. The probe succeeds. The cycle stabilizes.

What liveness probes should check

A liveness probe should check whether the application is in an unrecoverable broken state. Good liveness probe targets:

• An HTTP /healthz or /health endpoint that the application serves specifically for health checks
• A command that exits 0 only if a critical internal component is functioning
• A TCP connection to a port that the application is actively listening on

Bad liveness probe targets:

• External dependencies (a downstream database or third-party API). If the external service goes down, your liveness probe should not restart your Pod, which cannot fix the external problem.
• Expensive operations that consume significant CPU or I/O on every check

kubectl delete pod liveness-pod

Liveness probes catch unrecoverable internal failures. The next lesson covers readiness probes, which handle temporary unavailability without restarting the container.