Liveness vs readiness probes

WHAT THIS TESTS Probes are a frequent source of production incidents. The interviewer wants you to distinguish their effects precisely and apply judgment about when each is appropriate.

A GOOD ANSWER COVERS A liveness probe answers: is this container alive, or wedged and unrecoverable? If it fails, the kubelet restarts the container. A readiness probe answers: can this Pod serve requests right now? If it fails, the Pod is removed from the Service's endpoint list so no traffic is routed to it, but the container is not restarted. They use the same check types (HTTP, TCP, exec) but drive different actions.

A SCENARIO FOR READINESS ONLY An application that periodically reloads a large in-memory cache or fetches fresh configuration becomes briefly unable to serve correct responses, yet it is fully healthy and will recover on its own. A readiness probe pulls it out of rotation during the reload and restores it afterward. A liveness probe here would be harmful, since it might restart a perfectly healthy process mid-reload, causing needless churn.

COMMON WRONG ANSWERS Claiming readiness failure restarts the container. Treating the two probes as interchangeable. Setting an aggressive liveness probe that restarts slow-but-healthy apps, creating restart loops.

LIKELY FOLLOW-UPS What is a startup probe for? To protect slow-starting apps from premature liveness checks. What happens if you only set liveness? Traffic may hit a Pod before it is ready. Good probe tuning? Generous timeouts and failure thresholds.

ONE CONCRETE EXAMPLE A recommendation service rebuilds its model cache every few minutes, taking several seconds during which responses would be wrong. A readiness probe hitting /ready returns failure during the rebuild, removing the Pod from the Service; no liveness probe is set, so the healthy process is never restarted.