Container Probes — Liveness, Readiness, Startup

Kubernetes has three probe types (liveness, readiness, startup) and three probe mechanisms (httpGet, tcpSocket, exec). Understanding which probe causes which kubelet action — container restart vs EndpointSlice removal — and when to use startupProbe for slow-starting JVM/Python apps is essential for zero-downtime operations.

Overview

Container probes are how Kubernetes decides whether a container is healthy, ready to serve traffic, or still starting up. Each probe type maps to a distinct kubelet action.

Three probes, three actions

Liveness — Is the container healthy? — Restart the container
Readiness — Is it ready to serve traffic? — Remove it from the EndpointSlice
Startup — Is it still starting up? — Gate the other probes until startup completes

Where incidents come from

Most production incidents involving unexpected pod restarts or dropped traffic during rolling updates trace back to misconfigured probes.

Missing startupProbe on a slow-starting app — Unexpected restarts before the app finishes starting
readinessProbe too aggressive during rolling updates — Dropped traffic

> [!WARNING] Give every slow-starting app a startupProbe instead of stretching liveness timings.

Key concepts

livenessProbe: Kubelet action on failure: kill the container and restart it (per restartPolicy). Detects deadlocks, hangs, and processes that have stopped functioning without exiting. If livenessProbe keeps failing, the container enters CrashLoopBackOff with exponential backoff between restarts.
readinessProbe: Kubelet action on failure: set pod Ready condition to False → endpoint controller removes pod IP from EndpointSlice → Service stops routing traffic. The pod is NOT restarted. Use for: DB connection available, cache warm, dependencies up. Recovery is automatic when the probe succeeds again.
startupProbe: Blocks liveness and readiness probes until it succeeds. Gives slow-starting containers a configurable startup budget (failureThreshold × periodSeconds seconds) before any probe action is taken. On exhaustion: container is killed and restarted. Use for JVM apps, Python model loading, large dependency initialization.
EndpointSlice removal: When a pod's readinessProbe fails, the endpoint controller removes the pod's IP from the EndpointSlice backing the Service. kube-proxy (or the CNI's BPF dataplane) updates its forwarding rules to exclude the pod. New connections are not routed to it. This is the traffic gate for zero-downtime deployments.
Probe fields: failureThreshold and periodSeconds: failureThreshold × periodSeconds = maximum time before the probe takes action. For startupProbe: 30 × 10 = 300 seconds startup budget. For livenessProbe: 3 × 10 = 30 seconds to detect a hang. Always size these based on your actual app startup time and acceptable detection latency.

When to use it

Configuring a Spring Boot / JVM app that takes 60+ seconds to start — add startupProbe with a high failureThreshold × periodSeconds budget
Zero-downtime rolling updates — readinessProbe ensures new pods serve traffic before old pods terminate
Detecting deadlocked or memory-leaking processes that are alive but unresponsive — livenessProbe with httpGet to a meaningful health endpoint
Databases or TCP services without HTTP — use tcpSocket probe mechanism
Investigating why a pod is removed from Service load balancing intermittently — check readinessProbe failures in kubectl describe pod Events

Container Probes — Liveness, Readiness, Startup

Overview

Overview

Three probes, three actions

Where incidents come from

Key concepts

When to use it

More DevOps topics