Kubernetes Liveness Vs Readiness Probe

Legacy context

This site began as a technical archive focused on native XML and document-database systems, preserving practical guidance for developers and database administrators. The materials here reflect an era when schema flexibility and validation were central concerns for XML storage, with detailed discussions of SQL/XML, XQuery, and tools like the XMLTABLE function. The preserved excerpts emphasize real-world scenarios, such as adapting to evolving data formats and integrating XML with enterprise platforms.

Today, the archive serves as an independent educational reference for those exploring data management concepts, including the evolution from structured document stores to modern containerized deployments. Visitors may find historical context on topics like liveness and readiness probes useful when tracing how operational practices have developed. The content is offered for study and reflection, without implying current endorsement or ongoing operation of any referenced products or services.

Kubernetes Liveness vs. Readiness Probes: A Practical Comparison Guide. Kubernetes probes are the primary mechanism for controlling how the kubelet on each node interacts with your application containers. Two of the most commonly configured probe types are liveness probes and readiness probes. While both send HTTP requests, open TCP sockets, or execute commands inside a container, they serve fundamentally different purposes. Misunderstanding these differences is one of the most frequent causes of avoidable pod restarts, traffic black-holes, and cascading failures in production clusters.

This guide explains the purpose of each probe, how to decide which one you need, common mistakes, and a compact reference table you can keep handy.

What a Liveness Probe Does. A liveness probe answers one question: Is the container still alive, or is it stuck in a state from which it cannot recover?

The kubelet runs the liveness probe at a configured interval. If the probe fails a specified number of consecutive times (`failureThreshold`), the kubelet kills the container and restarts it according to the pod's `restartPolicy` (usually `Always`). This is a crash-recovery mechanism.

Typical use cases:. - A deadlock in your application where threads are blocked but the process is still running.

• A memory leak that eventually makes the app unresponsive.
• A worker process that has stopped processing messages but has not exited.

Important nuance: A liveness probe should not depend on external dependencies like a database or a downstream API. If your database is temporarily down, a liveness probe that checks the database will fail, causing Kubernetes to restart your container repeatedly. That restart loop does not fix the database; it only adds load and churn. Liveness probes should check internal state only.

A readiness probe answers a different question: Is this container ready to receive traff. If a readiness probe fails, Kubernetes does not restart the container. Instead, it removes the pod's IP address from the list of endpoints for all Services that match the pod's labels. The container keeps running, but it stops receiving new requests. When the probe starts succeeding again, the pod is re-added to the Service endpoints.

Typical use cases:. - Your application needs to load a large model or configuration file at startup; it is not ready to serve requests until that load completes.

• Your app depends on a downstream service (e.g., a database or a message queue). If that dependency is unavailable, the app can still run, but it cannot serve useful responses. A readiness probe that checks the dependency will temporarily remove the pod from rotation.
• You are doing a rolling update and want the new pod to receive traffic only after it has fully initialized.

Readiness probes are also used for startup ordering. For example, if Pod A must be fully initialized before Pod B can connect to it, Pod B can have a readiness probe that checks Pod A's readiness endpoint. However, this pattern is fragile; consider using init containers or headless Services with proper dependency management instead.

Key Differences at a Glance

---. Decision Criteria: Which Probe Do You Need?

Use this decision tree:

1. If the container process is running but cannot make progress and will never recover without a restart → use a liveness probe.
2. If the container can run but cannot serve requests right now (e.g., dependency down, still initializing) → use a readiness probe.
3. If you need both → configure both. They are independent and can coexist on the same container.
4. If your application takes a long time to start (more than a few seconds) → also add a `startupProbe`. The startup probe runs before liveness and readiness probes are evaluated. It protects slow-starting containers from being killed by an aggressive liveness probe. Once the startup probe succeeds, the liveness and readiness probes take over.

A common pattern for a web service:

• `startupProbe`: HTTP GET `/health/startup`, `failureThreshold: 30`, `periodSeconds: 2` (allows up to 60 seconds to start).
• `livenessProbe`: HTTP GET `/health/live`, `periodSeconds: 10`, `failureThreshold: 3`.
• `readinessProbe`: HTTP GET `/health/ready`, `periodSeconds: 5`, `failureThreshold: 3`.

The `/health/live` endpoint should return 200 if the process is alive and not deadlocked. The `/health/ready` endpoint should return 200 only if the app can actually serve requests (e.g., it has a valid DB connection, cache is warm, etc.).

Mistake 1: Using a liveness probe to check external dependencies. This is the most common error. If your database is down, a liveness probe that checks the DB will fail, and Kubernetes will restart your pod. The restart does not fix the DB. You now have a crash loop on top of a dependency outage. Fix: Use a readiness probe for external dependencies, and keep the liveness probe internal-only.

Mistake 2: Setting `initialDelaySeconds` too low. If your container takes 15 seconds to start listening on its port, but you set `initialDelaySeconds: 5`, the first probe will fail. With a `failureThreshold` of 3, the container may be killed before it ever becomes ready. Fix:** Use a startup probe with a generous `failureThreshold` and `periodSeconds`, or set `initialDelaySeconds` to a value slightly above your measured startup time.