Wire Readiness, Liveness and Startup Probes

Why this matters

Readiness decides traffic membership; liveness decides restarts; startup guards slow boots. A liveness probe on a slow starter restarts the app forever. A missing readiness probe sends traffic to pods still warming up. The exam probes your probes constantly, because miswired health checks are the most common self-inflicted outage in the field.

Concepts

Readiness gates endpoints: failing means removed from the Service, passing means traffic. It must test actual servability (a dependency ping or a ready flag), never mere aliveness. Liveness restarts the container when it fails past the threshold: reserve it for genuine deadlocks where a restart helps, never for transient dependency outages (restarting every replica during a database blip converts a partial outage into a full one).

Startup exists for slow boots: while it runs, liveness stays disabled, so a two-minute JVM warmup stops being murdered at 30 seconds. Once startup succeeds it never runs again for that container. Timings come from measurement: initialDelaySeconds covers the cold start you observed, periodSeconds matches how fast you need to notice, failureThreshold times period is your detection latency, and successThreshold stays 1 for liveness and readiness almost always.

Worked example

App needs 45 seconds cold, serves on 8080 with /ready and /healthz:

startupProbe:
  httpGet: { path: /healthz, port: 8080 }
  periodSeconds: 10
  failureThreshold: 12        # 120s of grace, then liveness takes over
readinessProbe:
  httpGet: { path: /ready, port: 8080 }
  periodSeconds: 5
livenessProbe:
  httpGet: { path: /healthz, port: 8080 }
  periodSeconds: 10
  failureThreshold: 3         # 30s of sickness, then restart

Events tell the story plainly: Readiness probe failed removes endpoints, Liveness probe failed ... will be restarted explains the restart loop, Startup probe failed explains why nothing else has started judging yet.

Exam notes

exec probes run inside the container namespace: a missing binary fails the probe, not the command logic. TCP probes only check the handshake, which proves the port listens and nothing about the app. And identical liveness plus readiness definitions double-punish one failure: separate their concerns even when they share an endpoint.