Kubernetes Liveness vs Readiness vs Startup Probes

Kubernetes Kubelet uses three distinct probe types to manage the health and traffic routing of containerized workloads:

1. Startup Probe (startupProbe)

• Purpose: Protects slow-starting legacy applications (e.g., Spring Boot JVM apps, large machine learning models loading into RAM, or cold cache warming) from premature termination.
• Mechanism: When configured, Kubelet runs only the startup probe. All liveness and readiness checks are completely disabled until the startup probe passes.
• Failure Action: If the startup probe fails more than failureThreshold times, the container is killed and restarted according to the pod's restartPolicy.

2. Readiness Probe (readinessProbe)

• Purpose: Determines whether a pod is currently capable of accepting network traffic from the Kubernetes Service load balancer.
• Mechanism: Evaluated continuously throughout the pod's life (e.g., every 5 seconds).
• Failure Action: If readiness fails, the Kubernetes Endpoint Controller immediately removes the Pod's IP address from the Endpoints / EndpointSlice object. The container is NOT killed or restarted. It remains running, allowing it to cool down, drain backlogs, or reconnect to warm caches.

3. Liveness Probe (livenessProbe)

• Purpose: Detects catastrophic, unrecoverable internal failures (such as Java thread deadlocks, fatal memory leaks, or corrupted internal state).
• Mechanism: Evaluated continuously (e.g., every 10–15 seconds).
• Failure Action: If liveness fails for failureThreshold consecutive checks, Kubelet immediately sends a SIGKILL signal to terminate the container and spawns a fresh replacement.