Kubernetes Liveness Vs Readiness Probe

Legacy context

Legacy context. This site is an independent educational reference focused on software operations and technical documentation. The material presented here is drawn from preserved historical notes and public technical discussions, offered for study and general understanding.

The content is provided as-is, without representation of ongoing business activity, current product availability, or professional certification. No affiliation with any commercial entity is claimed, and no services are offered.

Readers are encouraged to treat all excerpts as archival material, useful for exploring concepts in software development and system administration. The site does not collect personal data beyond standard, non-identifying technical logs, and no third-party advertising is employed.

For clarity, this resource is maintained solely for educational purposes, and any technical examples should be verified against current official documentation before application in production environments.

Kubernetes Liveness vs. Readiness Probes: A Practical Comparison. Kubernetes probes are the primary mechanism for detecting container health and controlling traffic flow. Misconfiguring them is one of the most common causes of pod restarts, cascading failures, and deployment rollouts that never complete. This guide compares liveness and readiness probes, explains when to use each, and highlights frequent mistakes.

Core Definitions and Behavioral Differences. Both probe types run the same three checks: HTTP GET, TCP socket, or exec command. The difference is what Kubernetes does with the result.

Liveness probe answers: "Is the container alive, or is it stuck in a deadlock?" If the probe fails, the kubelet kills the container and restarts it according to the `restartPolicy` (usually Always). Liveness failures do not remove the pod from Service endpoints. The pod remains reachable until it is killed and recreated.

Readiness probe answers: "Is the container ready to serve traffic?" If the probe fails, the kubelet marks the pod as `NotReady` and removes its IP address from all Service endpoints. The container is not killed. It stays running, and the probe keeps being checked. When the probe succeeds again, the pod is re-added to endpoints.

Startup probe (optional) is a third type that delays liveness and readiness checks until the container has finished initializing. It is useful for applications with slow first-time startup (e.g., loading large models, compiling caches). During the startup probe period, liveness and readiness are not evaluated.

Decision Criteria: Which Probe to Use

Use the following rules as a baseline, then adjust for your application's behavior.

Use a liveness probe when:

• The application can enter a deadlock or infinite loop but the process does not exit.
• The application has a known "stuck" state that only a restart can fix (e.g., a goroutine leak that exhausts memory, a mutex that is never released).
• You have a crash-looping container that needs automatic recovery.

Do NOT use a liveness probe when:

• The application is single-threaded and a slow request blocks the probe endpoint. A liveness failure would restart the pod unnecessarily.
• The probe depends on external services (database, cache). If the database is down, the liveness probe fails, and Kubernetes restarts the pod—but the restart does not fix the database. This creates a restart storm.

Use a readiness probe when:

• The application needs time to load configuration, connect to dependencies, or warm up caches before accepting traffic.
• The application can temporarily degrade (e.g., it loses connection to a backend) but can recover without a restart. The readiness probe should fail during degradation, removing the pod from Service endpoints, and succeed again when recovery completes.
• You are doing rolling updates. The readiness probe gates when a new pod is considered "available" and when the old pod is terminated.

Use both when:

• The application has a slow startup (use a startup probe to delay liveness) and also has runtime dependencies that can fail transiently (readiness probe).
• You want to distinguish "process is alive but not functional" (liveness) from "process is functional but not ready for traffic" (readiness).

Common Mistakes and Failure Modes

1. Using the same endpoint for both probes

Many developers point both probes at `/healthz`. This is acceptable only if the endpoint returns 200 only when the app is both alive and ready. In practice, this conflates two concerns. If the app is alive but not ready (e.g., it lost its database connection), the liveness probe fails, and Kubernetes restarts the pod. The restart does not restore the database connection; it just adds startup delay. Instead, use `/healthz` for liveness (always returns 200 if the process is running) and `/readyz` for readiness (returns 200 only when dependencies are reachable).

1. Setting `initialDelaySeconds` too low

If the probe starts before the application has bound its listening port, the first few checks fail. For liveness, this can cause a restart loop before the app even finishes booting. For readiness, it just delays traffic, which is less harmful. Use a startup probe with a generous `failureThreshold` (e.g., 30 failures at 1-second intervals) to cover the entire startup window, then set liveness and readiness to begin after startup completes.

1. Ignoring `failureThreshold` and `periodSeconds` interaction

Default values are `periodSeconds: 10`, `failureThreshold: 3`. That means a probe must fail three consecutive times (30 seconds) before action is taken. For a liveness probe, this is often too slow for a truly stuck process. Consider lowering `periodSeconds` to 5 and `failureThreshold` to 2 for latency-sensitive apps. For readiness, a higher threshold (e.g., 5) prevents flapping when the app briefly hiccups.

1. Probing an endpoint that has side effects

The probe HTTP handler must be read-only. If your `/healthz` handler increments a counter, writes to a log, or triggers a database query, every probe check adds load. Under high traffic, this can distort metrics and even cause the probe to fail because the handler is slow. Keep probe handlers minimal: return 200 immediately if the process is alive, and do a lightweight dependency check for readiness (e.g., a TCP connection to the database with a 1-second timeout, not a full query).