Liveness, Readiness and Startup Probes

Observability and Maintenance / Guide 40 of 44 / Intermediate

• Kubernetes1.36.4
• Cluster4 nodes
• Runtimecontainerd 2.2.6
• CNICalico v3.32.1
• TimeAbout 15 min

While a startupProbe is defined and has not yet succeeded, the liveness and readiness probes are disabled entirely. Once it succeeds it never runs again and the other two take over. That handover is the whole feature: slow start-up and fast failure detection stop being a trade-off.

This guide includes

Use this when an application that needs time to start is being killed before it gets there. This matters because a liveness probe gives up on a fixed schedule, and a startup probe exists precisely to hold it off until the app is up.

• running an application that takes forty seconds, and watching liveness kill it
• adding a startup probe to the identical container and watching it come up cleanly
• doing the arithmetic - failureThreshold times periodSeconds is the budget you actually get

Before you start

• A cluster and kubectl.
• The session creates namespace ckad-start with a Pod whose container sleeps 40 seconds before starting nginx - once with only a liveness probe, once with a startup probe as well.

1. 1

   An application that takes 40 seconds

2. 2

   The same application with a startup probe

3. 3

   The arithmetic that matters

Official sources

• Configure Liveness, Readiness and Startup Probes
• Protect slow starting containers
• Pod Lifecycle