Master Kubernetes Liveness Probes: When, Why, and How to Use Them

What Is a Kubernetes Liveness Probe?

Kubernetes Liveness Probes are a mechanism that determines whether a container inside a pod is still alive and running correctly. If a probe fails, kubelet automatically restarts the container to restore service.

Why Use Liveness Probes?

Detect deadlocked applications

Identify processes that become unresponsive

Handle internal errors where the process does not exit

Probe Types

1️⃣ HTTP GET Probe

Sends an HTTP request to a specified endpoint.

2xx or 3xx response → probe succeeds

Other response codes → probe fails

2️⃣ TCP Socket Probe

Attempts to open a TCP connection to a given port.

Port reachable → probe succeeds

Port unreachable → probe fails

3️⃣ Exec Probe

Executes a command inside the container.

Command returns 0 → probe succeeds

Non‑zero return → probe fails

Other Kubernetes Probe Mechanisms

Liveness Probe

Readiness Probe – determines if a pod is ready to receive traffic (does not restart the container).

Startup Probe – checks if an application has finished starting; while it fails, Liveness and Readiness probes are disabled.

How Liveness Probes Work

The kubelet executes the configured probe actions (ExecAction, TCPSocketAction, HTTPGetAction, or gRPC probe in newer versions). Based on the result, it either does nothing, records an event, or restarts the container according to the pod’s restartPolicy.

When to Use a Liveness Probe

Use it when a pod appears to be running but the application is actually dead, such as deadlocks, unresponsive ports, or blocked threads.

When Not Needed

If the application exits on fatal errors (e.g., NGINX), kubelet will restart it automatically via restartPolicy, so an additional Liveness Probe may be unnecessary.

Defining a Liveness Probe

In a Pod YAML, the livenessProbe field defines the probe.

Example: HTTP Probe

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: myapp:latest
    livenessProbe:
      httpGet:
        path: /health
        port: 8080
      initialDelaySeconds: 3
      periodSeconds: 5

Example: Exec Probe

livenessProbe:
  exec:
    command: ["cat", "/tmp/healthy"]
  initialDelaySeconds: 5
  periodSeconds: 10

Common Liveness Probe Configuration Parameters

initialDelaySeconds

: delay before the first probe periodSeconds: interval between probes timeoutSeconds: timeout for each probe successThreshold: consecutive successes required failureThreshold: consecutive failures before taking action

How to Verify Probe Effectiveness

Inspect pod events: kubectl describe pod <pod-name> Check container logs: kubectl logs <pod-name> List pod status: kubectl get pods Manually call the probe endpoint, e.g.,

curl http://<pod-ip>:<port>/health

Typical Failure Reasons & Troubleshooting

1️⃣ Application Starts Too Slowly

Increase initialDelaySeconds Use a Startup Probe

2️⃣ Wrong Path or Port

Verify the endpoint path is correct

Ensure the port matches the container’s listening port

3️⃣ Resource Constraints Cause Timeouts

Adjust timeoutSeconds Set appropriate CPU/memory requests and limits

Best Practices

Keep probe logic simple and lightweight

Combine Liveness with Readiness probes

Avoid tying the probe to core business logic

Set reasonable failure thresholds to prevent frequent restarts

Periodically review and tune probe configurations

Integrate probes with monitoring and alerting systems

Conclusion

Properly configuring Liveness, Readiness, and Startup probes dramatically improves pod stability and availability. The essential factor is understanding the application’s behavior and designing probes that match its characteristics.