A startup probe is a Kubernetes container health check for applications that need extra time to initialize. While it runs, Kubernetes does not run the container’s liveness probe. After the startup probe succeeds, Kubernetes switches to the liveness probe, allowing fast detection of later failures without restarting the application prematurely. section 6.2.6
A startup probe may fail during initialization; failure means only that the application is not ready yet. Kubernetes terminates the container after the configured failure threshold is reached, and the pod’s restart policy determines whether it is restarted. section 6.4.2
Allowing a slow application to warm up
A Node.js application can use an HTTP startup probe every 10 seconds with a failure threshold of 12. This gives it up to 120 seconds to respond successfully. A liveness probe can then run every 5 seconds with a threshold of 2, detecting ordinary health failures within normal operation. section 6.2.6
Listing 6.2 Using a combination of a startup and a liveness probe
...
containers:
- name: kiada
image: luksa/kiada:0.1
ports:
- name: http
containerPort: 8080
startupProbe:
httpGet:
path: / #1
port: http #1
periodSeconds: 10 #2
failureThreshold: 12 #2
livenessProbe:
httpGet:
path: / #3
port: http #3
periodSeconds: 5 #4
failureThreshold: 2 #4
Use the manifest to see the startup probe’s HTTP endpoint, timing budget, and handoff to a faster liveness probe. section 6.2.6
Choose a startup probe when:
- The application takes minutes to initialize and increasing liveness-probe delays would make recovery from later failures too slow. section 6.2.6
- The container needs a forgiving initialization check followed by a quicker steady-state health check. section 6.2.6
