What is the main purpose of a startup probe in a Kubernetes pod?
Think about what happens when an app takes time to start and how Kubernetes knows when to begin health checks.
The startup probe is used to determine if the application inside the container has started. It prevents Kubernetes from killing the pod prematurely by delaying liveness and readiness probes until the app is ready.
Given this startup probe configuration, what will happen if the probe fails continuously?
startupProbe:
exec:
command:
- cat
- /tmp/healthy
failureThreshold: 3
periodSeconds: 5Calculate failureThreshold multiplied by periodSeconds to find the restart delay.
The failureThreshold of 3 and periodSeconds of 5 means Kubernetes waits 3 failures spaced 5 seconds apart (total 15 seconds) before restarting the container.
Which of the following YAML snippets correctly configures a startup probe that checks HTTP path /healthz on port 8080 every 10 seconds, with a failure threshold of 5?
Look for the correct probe type and matching period and failureThreshold values.
Option A uses httpGet with the correct path, port, periodSeconds, and failureThreshold as requested. Option A swaps period and threshold. Option A uses exec with curl which is not recommended. Option A uses tcpSocket which does not check HTTP path.
A pod with a startup probe keeps restarting even though the application eventually starts. What is the most likely cause?
Check the probe configuration carefully for correctness.
If the startup probe is misconfigured (wrong command or path), it will fail repeatedly causing Kubernetes to restart the pod even if the app starts later.
For an application that takes a long time to start, what is the best practice when configuring probes in Kubernetes?
Think about how Kubernetes decides when to start health checks and restart containers.
Startup probes are designed to handle slow-starting apps by delaying liveness and readiness probes until the app is confirmed started, avoiding unnecessary restarts.