Q: What are the different types of probes, and which probe acts first — Startup, Readiness, or Liveness?
Detailed breakdown of the Kubernetes health probe evaluation lifecycle, explaining why startupProbe runs first and how readiness and liveness interact to prevent deployment death spirals.
🛠️ Production Runbook & Step-by-Step Resolution
The Execution Hierarchy (Startup Probe Acts First)
On container launch, the kubelet runs the startupProbe. While it runs, liveness and readiness probes do not execute. If the startup probe fails to succeed within initialDelaySeconds + (periodSeconds * failureThreshold), the container is killed and restarted.
Readiness Probe: Controls Traffic Routing
Once startup passes, the readinessProbe executes periodically. If it fails, the container is NOT restarted. Instead, the kubelet removes the Pod IP from the Service EndpointSlice so it stops receiving user traffic.
Liveness Probe: Controls Container Lifecycle (Self-Healing)
The livenessProbe detects deadlocks where the process is running but cannot make progress. If it fails, the kubelet kills the container and invokes the restartPolicy.
- StartupProbe acts first: all readiness and liveness checks are disabled until it succeeds.
- ReadinessProbe controls routing: failure strips the pod IP from Endpoints without restarting the container.
- LivenessProbe controls restarts: failure triggers container termination (SIGTERM/SIGKILL) for deadlocks.
- Use startupProbe with high failureThreshold for legacy apps instead of huge initialDelaySeconds.