Liveness, Readiness, Startup Probes

Kubernetes doesn't know if your app is healthy unless you tell it how to check. That's what probes are: small, repeated health checks the kubelet runs against each container, each with a different consequence when it fails.

Three probes, three different jobs

• Liveness — "is this container still working, or has it wedged?" A failing liveness probe gets the container killed and restarted by the kubelet, right there on the same node. This is self-healing at the container level, one layer below the ReplicaSet-level self-healing you saw in Module 1.
• Readiness — "should this pod receive traffic right now?" A failing readiness probe does not restart anything — it just pulls the pod out of every Service's endpoints (remember Module 4: Services route only to pods matching their selector and currently Ready). The pod keeps running, Kubernetes just stops sending it requests.
• Startup — "has this container finished booting yet?" While a startup probe is defined and hasn't yet succeeded, liveness and readiness probes are held off entirely. This exists for slow-starting apps (a JVM with a big warmup, a database replaying a WAL) that would otherwise get killed by liveness for being "unhealthy" when they're really just not done starting.

Why readiness failures are the quiet kind

A liveness failure is loud — you'll see RESTARTS climb and kubectl describe pod will show it. A readiness failure is quiet: the pod shows Running, restart count stays at 0, and the only visible symptom is that a Service's endpoint list is shorter than expected (or empty) and traffic silently has nowhere to go. This is one of the most common "it's not working and nothing looks wrong" situations in real clusters — the fix is always the same: check kubectl get endpointslice -l kubernetes.io/service-name=<service> (the modern, non-deprecated equivalent of kubectl get endpoints, per Module 4), then kubectl describe pod on the pods that should be backing it, and look at the probe's own failure message in the Events section.

Getting probe config wrong

All three probes are usually httpGet (hit a path/port and expect 2xx-3xx), tcpSocket (just open a connection), or exec (run a command, 0 means healthy). The most common real-world bug is embarrassingly simple: the probe's path or port doesn't match what the app actually serves — a typo, or a path that changed when the app was updated but the manifest wasn't. That's exactly the bug in this lesson's lab.

The infrastructure analogy

This is the same job a load balancer's health check endpoint does in a traditional setup — except here it's defined per-pod, checked by the kubelet locally rather than by a remote LB polling over the network, and wired automatically into Service routing rather than something you configure separately in two places and hope stays in sync.