1. Introduction to Liveness Probes

Kubernetes Pods can contain containers that may crash, hang, or enter an unresponsive state due to software bugs, deadlocks, or resource issues.

In such cases:

• The process might still be running, so the container won’t automatically restart.
• Kubernetes needs a way to detect and recover from such issues.

This is where Liveness Probes come in.

A Liveness Probe is a health check mechanism that determines whether the container inside a Pod is still alive and functioning properly.

If a container fails the liveness probe, the kubelet restarts it automatically to recover from the failure.

2. Why You Need Liveness Probes

Without a Liveness Probe:

• Kubernetes assumes the container is healthy as long as the process hasn’t exited.
• Crashed or frozen apps will keep running, causing issues in production (e.g., timeouts, stuck queues).

With a Liveness Probe:

• Kubernetes periodically checks container health.
• If it detects that the app is not responsive, it restarts the container to restore normal behavior.

3. Liveness Probe Types in Kubernetes

Kubernetes supports three types of liveness probes:

A. HTTP GET Probe

The kubelet performs an HTTP GET request to a specified endpoint in the container.

Behavior:

• Success: HTTP status code in the range 200–399
• Failure: Status code outside 200–399 or no response

Example:

apiVersion: v1
kind: Pod
metadata:
  name: liveness-http
spec:
  containers:
    - name: liveness
      image: luksa/kubia-unhealthy
      ports:
        - containerPort: 8080
      livenessProbe:
        httpGet:
          path: /
          port: 8080
        initialDelaySeconds: 3
        periodSeconds: 3
        failureThreshold: 3

Key Fields:

• httpGet.path: URL path to probe, e.g., /health
• initialDelaySeconds: Wait time before starting probe after container starts
• periodSeconds: How often to perform the probe
• failureThreshold: Number of failures before restarting (default is 3)

In the above example, the container becomes unhealthy after every 5th request. If it fails 3 probes in a row, the container will be automatically restarted.

Commands:

kubectl apply -f liveness-http-test.yaml
kubectl get pod liveness-http
kubectl describe pod liveness-http
kubectl logs liveness-http --previous  # View logs from previous instance

B. TCP Socket Probe

Kubelet attempts to open a TCP connection to the specified port. If the connection is successful, the container is considered healthy.

Example:

apiVersion: v1
kind: Pod
metadata:
  name: liveness-tcp
spec:
  containers:
    - name: goproxy
      image: k8s.gcr.io/goproxy:0.1
      ports:
        - containerPort: 8080
      livenessProbe:
        tcpSocket:
          port: 8080
        initialDelaySeconds: 3
        periodSeconds: 3

TCP probes are useful for simple server health checks where an open port means the service is accepting connections.

C. Exec Probe

Executes a command inside the container, and evaluates success based on the exit status.

• Exit code 0: Success
• Any other code: Failure

Example:

apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec
spec:
  containers:
    - name: liveness
      image: k8s.gcr.io/busybox
      args:
        - /bin/sh
        - -c
        - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
      livenessProbe:
        exec:
          command:
            - cat
            - /tmp/healthy
        initialDelaySeconds: 5
        periodSeconds: 5

Explanation:

• Container creates /tmp/healthy for the first 30 seconds.
• The cat /tmp/healthy command succeeds while the file exists.
• After 30s, the file is deleted and the liveness probe fails.
• Container is then restarted.

Note: Exec probes are powerful, but can cause problems and are generally not recommended for most production workloads.

4. Best Practices for Liveness Probes

To use liveness probes effectively and safely, follow these practices:

Always Define a Liveness Probe

• Kubernetes has no other way to detect frozen apps.
• Helps ensure self-healing behavior.

Use a Dedicated Health Endpoint

• Prefer /health or /live routes in your app.
• This endpoint should be:
  • Lightweight
  • Unauthenticated
  • Independent of external systems (e.g., databases, 3rd-party APIs)

Use initialDelaySeconds

• Set it based on your app’s startup time.
• Without this, probes may run too early, causing premature restarts.

initialDelaySeconds: 10

Don’t Use Liveness Probe for Dependency Checks

• For example, if a database is down, restarting the app won’t help.
• Probe should only check the app’s internal health, not external services.

Avoid Exec Probes

• Exec-based probes have known issues:
  • Resource overhead
  • Compatibility problems with certain container runtimes

Do Not Duplicate Readiness and Liveness Probes

• Readiness probe checks if the app is ready to serve traffic.
• Liveness probe checks if the app is alive and recoverable.
• They should not be identical.

Keep It Fast

• The /health endpoint should respond in under 1 second.
• Avoid long-running logic in your probe.

Handle Uncaught Exceptions Properly

• If the application hits a fatal error:
  • Let the process exit.
  • Kubernetes will automatically restart the container.

5. Summary Table

Probe Type	How it Works	Use Case
HTTP GET	Sends HTTP GET to endpoint (e.g., /health)	Web applications with REST APIs
TCP Socket	Tries to open a TCP connection on port	TCP services, custom protocols
Exec	Runs a command inside the container	Legacy apps or where HTTP/TCP checks aren’t possible

6. Conclusion

A well-configured Liveness Probe is a powerful recovery mechanism in Kubernetes. It ensures your application can self-heal by restarting stuck or unresponsive containers automatically.

In Short:

• Always define a Liveness Probe.
• Use initialDelaySeconds wisely.
• Separate Liveness and Readiness concerns.
• Keep the health check internal and lightweight.
• Use HTTP or TCP probes in preference to Exec.