Some programs take a while before they answer: a Java service loading classes, an app warming a cache, a database replaying its log. The liveness probe from two lessons ago does not know that. It starts asking at second one.

The problem

The app never gets to finish. RESTARTS climbs, the Events say Liveness probe failed, and nothing is actually wrong with the program.

The fix

A startup probe runs first and alone. Until it passes once, the liveness and readiness probes are held back. After it passes it is never run again.

startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  periodSeconds: 5
  failureThreshold: 12     # 5s × 12 = up to 60s to start
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  periodSeconds: 5
  failureThreshold: 3

The same path can serve both. What differs is the budget: the startup probe allows a minute, the liveness probe allows fifteen seconds once the app is up.

Why not initialDelaySeconds

initialDelaySeconds on the liveness probe also works, but the delay is fixed. Set it to 60 and every restart waits a full minute even when the app is ready in five seconds. A startup probe hands over the moment the app answers.

Reading it

kubectl describe pod lists a third probe line:

Startup:    http-get http://:8080/healthz delay=0s timeout=1s period=5s #success=1 #failure=12
Liveness:   http-get http://:8080/healthz delay=0s timeout=1s period=5s #success=1 #failure=3

Events for a failing startup probe read Startup probe failed: ….