Kubernetes Readiness

Kubernetes readiness determines whether a container is currently able to receive traffic. A readiness probe lets Kubernetes remove an unhealthy or unready Pod from Service endpoints without necessarily restarting the container.

A readiness probe is a health check configured for a container. Kubernetes periodically evaluates the probe, and a successful result means the container is considered ready to serve requests.

For an HTTP-based Java backend, a common approach is to expose a lightweight health endpoint and configure Kubernetes to call it. If the application is starting, overloaded in a way that prevents safe request handling, or temporarily unable to serve traffic, the endpoint can report failure and Kubernetes stops routing Service traffic to that Pod.

Readiness is different from liveness. A failed readiness probe normally means "do not send traffic here," whereas a failed liveness probe can cause Kubernetes to restart the container. Readiness therefore handles temporary inability to serve requests without treating it as a process failure.

Readiness can also be affected by startup behavior. If an application needs substantial initialization time, configuring appropriate probe delays or a startup probe can prevent Kubernetes from treating normal startup as an unhealthy state.

For a Java backend, the readiness check should be cheap and representative of the application's ability to handle requests. Whether dependencies such as a database should affect readiness depends on the application's architecture and failure-handling strategy; blindly checking every dependency can make an otherwise useful instance unavailable during partial outages.

Key points

• A readiness failure removes a Pod from normal Service traffic.
• Readiness answers whether the application should receive requests now.
• Liveness and readiness have different purposes: restart versus traffic eligibility.
• HTTP, TCP, and command-based probes can be used to determine readiness.
• Probe timing and startup behavior should match the application's initialization characteristics.

Interview questions

What happens when a readiness probe starts failing?

Kubernetes marks the container as not ready. The corresponding Pod is then excluded from normal Service traffic while the readiness condition remains failed. Other healthy and ready Pods can continue serving requests. Kubernetes does not restart the container solely because its readiness probe failed.

What is a Kubernetes readiness probe?

A readiness probe checks whether a container is currently able to handle requests. When the probe fails, Kubernetes does not normally route Service traffic to that Pod. The container is not necessarily restarted because failure of readiness does not mean the process has crashed. This is useful for temporary conditions such as initialization or an application becoming unable to serve requests safely.

How would you implement readiness for a Java backend?

I would expose a lightweight endpoint that represents whether the application can safely handle requests, then configure an HTTP readiness probe for that endpoint. The endpoint should avoid expensive work and should reflect the application's actual serving state. I would also configure probe timing around the application's startup characteristics. If initialization is slow, I would consider a startup probe so readiness does not have to compensate for normal startup delays.

What is the difference between readiness, liveness, and startup probes?

Readiness determines whether the application should receive traffic. Liveness determines whether the container is still functioning well enough to remain running, and a failed liveness check can lead to a restart. A startup probe is useful when an application needs significant time to initialize and prevents normal startup from being treated as a failure. These probes answer different operational questions and should not be treated as interchangeable.