What probes do
In Kubernetes, probes are periodic checks that tell the system about a container's state. A readiness probe reports whether a container is ready to receive traffic, and a liveness probe reports whether it is still alive and healthy or needs restarting. These probes directly affect how Kubernetes routes traffic and whether it restarts containers. Understanding what each probe controls, and configuring them thoughtfully, is important, because misconfigured probes can cause serious, self-inflicted problems like needless restarts and outages.
How readiness affects routing
The readiness probe controls traffic routing: Kubernetes only sends requests to containers that report ready. When a container is starting up or temporarily busy, a readiness probe lets it say 'not yet', so traffic waits until it is truly ready, preventing errors from hitting a container that cannot serve yet. If the probe later reports not ready, Kubernetes stops routing traffic there without restarting it. Readiness is thus about directing traffic only to containers that can actually handle it.
How liveness affects restarts
The liveness probe controls restarts: if it reports a container is unhealthy (for example, stuck or deadlocked), Kubernetes restarts that container to recover it. This is powerful for self-healing, automatically recovering a hung application, but it is also where misconfiguration bites. A liveness probe that is too aggressive or checks the wrong thing can decide a healthy container is unhealthy and restart it unnecessarily, so its configuration must genuinely reflect whether the container needs restarting.
Common misconfigurations
Common probe mistakes cause real harm. Timeouts or thresholds set too tight can mark a slow-but-healthy container as failing, triggering needless restarts. A liveness probe that checks external dependencies, rather than just the container itself, is especially dangerous. Confusing readiness and liveness, using one where the other is appropriate, also causes trouble. These misconfigurations can turn probes from a safety feature into a source of instability, so it is worth getting their targets and timing right.
Do not let dependencies cause restart storms
A key principle: a dependency outage should not make every application container restart continuously. If liveness probes check a shared dependency (like a database) and that dependency goes down, every container can be deemed unhealthy and restarted at once, worsening the outage with a restart storm, right when you can least afford it. Liveness should reflect the container's own health, not external dependencies, so a dependency failure degrades gracefully instead of triggering cascading, continuous restarts across the whole application.
The bottom line
Kubernetes readiness probes control whether a container receives traffic, and liveness probes control whether it is restarted. Misconfigurations, overly tight timings, or liveness probes that check external dependencies, cause needless restarts and even restart storms during a dependency outage. The guiding rule is that liveness should reflect a container's own health, so dependency failures do not make every container restart continuously. Configuring probes thoughtfully keeps them a safety feature, not a hazard.
Related on Skillo
See also: What is Kubernetes? Explained for beginners, How to troubleshoot a Docker container that keeps restarting.
Sources
Published date reflects the original event date (2026-10-23). This article is original Skillo editorial written from the sources above; facts were verified in September 2026.
Leave a Reply