What's the difference between liveness, readiness, and startup probes?
Quick Answer
Liveness decides whether to restart a container; readiness decides whether the pod receives Service traffic; startup protects slow-booting apps by delaying the liveness/readiness checks until the app has started.
Detailed Answer
Readiness gates traffic: while it fails, the pod is removed from Service endpoints but not restarted — perfect for 'temporarily busy' or 'warming caches.' Liveness gates restarts: if it fails past the threshold, the kubelet kills and restarts the container — for detecting deadlocks/hangs the process can't recover from. The danger is a too-aggressive liveness probe restarting a healthy-but-slow app, which is why the startup probe exists: it runs first and, until it passes, disables liveness/readiness, giving a slow app (large JVM, migrations) time to boot without being killed. Use all three thoughtfully: readiness for load management, liveness only for truly unrecoverable states, and startup for anything with a long or variable boot time. Misconfigured liveness probes are a top cause of self-inflicted CrashLoopBackOff.
Code Example
startupProbe: { httpGet: { path: /healthz, port: 8080 }, failureThreshold: 30, periodSeconds: 5 } # up to 150s to boot
readinessProbe:{ httpGet: { path: /ready, port: 8080 }, periodSeconds: 5 }
livenessProbe: { httpGet: { path: /healthz, port: 8080 }, periodSeconds: 10 }Interview Tip
Say the failure mode out loud: 'an over-eager liveness probe restarts a slow-but-healthy app — that's what startupProbe fixes.' Interviewers love that you know probes can cause outages.