Liveness, Readiness & Startup Probes

Three Probes, Three Jobs

• Liveness: failure restarts the container. Use it to detect hangs and deadlocks — nothing else.
• Readiness: failure removes the pod from Service endpoints. Traffic stops; no restart.
• Startup probe: runs until it succeeds, disabling liveness/readiness for that period — the correct tool for slow-booting apps.

A liveness endpoint that checks the database will restart healthy-during-dependency-outage containers and multiply the outage. Readiness, by contrast, is exactly where dependency checks belong: the pod keeps running but stops receiving traffic until dependencies recover.

Probe Configuration

startupProbe:
  httpGet: { path: /healthz, port: 8080 }
  failureThreshold: 30
  periodSeconds: 10        # up to 5 minutes to boot
livenessProbe:
  httpGet: { path: /live, port: 8080 }
  periodSeconds: 10
  timeoutSeconds: 1
  failureThreshold: 3
readinessProbe:
  httpGet: { path: /ready, port: 8080 }
  periodSeconds: 5
  successThreshold: 1

Handlers: httpGet (200–399 passes), tcpSocket, exec (exit 0 passes), and grpc (status OK) for gRPC servers. Defaults are period 10s, timeout 1s, failureThreshold 3, initialDelaySeconds 0 — always set them explicitly so intent is reviewable.

Pitfalls and Interview Angles

Restart storms. Liveness hitting a slow dependency → restarts → more load on the dependency → loop. Symptom: kubectl get pod shows climbing RestartCount with ready periods in between.

Slow starters killed. Without a startup probe, liveness begins after initialDelaySeconds — a boot that takes longer than the delay is killed repeatedly. Give the startup probe enough attempts to cover worst-case boot.

All traffic missing one pod. Readiness path wrong or successThreshold misread → pod runs but endpoints exclude it; confirm with kubectl get endpoints and kubectl describe pod.

Interview angle: state the exact effect of each probe failing, and justify your timing numbers against real boot and dependency behavior.