Checking the Patient's Vitals
A Pod isn't just created and forgotten. It moves through a defined lifecycle:
| Phase | Meaning |
|---|---|
Pending |
The Pod has been accepted by the cluster but containers haven't started yet (e.g., image is still being pulled). |
Running |
At least one container is running. |
Succeeded |
All containers exited with code 0 (success). Common for batch jobs. |
Failed |
At least one container exited with a non-zero code and won't be restarted. |
Unknown |
The node hosting the Pod has lost contact with the control plane. |
To manage applications reliably, Kubernetes needs to know the real-time health of the containers inside a Pod. It does this using Probes — health checks you define in the Pod spec. There are three types, and they serve distinct purposes:
1. Startup Probe — "Are you awake yet?"
Runs first, before any other probe. It tells Kubernetes when the application has finished initializing. Until the startup probe succeeds, liveness and readiness probes are disabled. This is critical for slow-starting applications (like a Java app loading a large classpath) that would otherwise be killed by a liveness probe before they finish booting.
2. Liveness Probe — "Are you still alive?"
Runs continuously after startup. If this probe fails, Kubernetes assumes the container is stuck (e.g., in a deadlock) and restarts it. Use this to recover from states the application cannot recover from on its own.
3. Readiness Probe — "Are you ready to serve traffic?"
Runs continuously after startup. If this probe fails, Kubernetes does not restart the container — it simply removes the Pod from the Service's load balancer rotation, stopping new traffic from reaching it. When the probe passes again, traffic resumes. Use this for temporary overload situations or when the app is waiting for a dependency (like a database connection) to become available.
Each probe can be implemented as an HTTP GET request, a TCP socket check, or an arbitrary shell command executed inside the container, and each is independently configured with its own path, port, and timing — a startup probe might tolerate up to five minutes of failures before giving up, while a liveness probe checked every 15 seconds and a readiness probe checked every 5 seconds run continuously once startup succeeds. Note that a liveness check and a readiness check typically hit separate endpoints (/healthz vs /ready). A common mistake is using the same endpoint for both — but a liveness check should only verify the process isn't deadlocked, while a readiness check should verify all dependencies are reachable.