Startup probe concept in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Purpose of Startup Probe in Kubernetes

What is the main purpose of a startup probe in a Kubernetes pod?

A To check if the application inside the container has started successfully before other probes run

B To continuously monitor the CPU usage of the container

C To restart the pod immediately when the container crashes

D To manage network traffic routing to the pod

💡 Hint

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.

💻 Command Output

intermediate

Startup Probe Failure Behavior

Given this startup probe configuration, what will happen if the probe fails continuously?

startupProbe:
  exec:
    command:
    - cat
    - /tmp/healthy
  failureThreshold: 3
  periodSeconds: 5

A The container will be restarted immediately after the first failure

B The container will be restarted after 3 seconds of continuous failure

C The container will never restart regardless of failures

D The container will be restarted after 15 seconds of continuous failure

💡 Hint

Calculate 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.

❓ Configuration

advanced

Correct Startup Probe YAML Configuration

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?

A

startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  periodSeconds: 10
  failureThreshold: 5

B

startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  periodSeconds: 5
  failureThreshold: 10

C

startupProbe:
  exec:
    command:
    - curl
    - http://localhost:8080/healthz
  periodSeconds: 10
  failureThreshold: 5

D

startupProbe:
  tcpSocket:
    port: 8080
  periodSeconds: 10
  failureThreshold: 5

💡 Hint

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.

❓ Troubleshoot

advanced

Diagnosing Startup Probe Failures

A pod with a startup probe keeps restarting even though the application eventually starts. What is the most likely cause?

A The readiness probe is misconfigured and causing restarts

B The pod has insufficient CPU resources causing slow startup

C The startup probe command or HTTP path is incorrect, causing probe failures

D The container image is missing required environment variables

💡 Hint

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.

✅ Best Practice

expert

Best Practice for Using Startup Probe with Slow-Starting Apps

For an application that takes a long time to start, what is the best practice when configuring probes in Kubernetes?

A Set very short liveness probe intervals to detect failures quickly

B Use a startup probe to delay liveness and readiness probes until the app is ready, preventing premature restarts

C Disable readiness probes to avoid blocking traffic

D Use only readiness probes and no startup or liveness probes

💡 Hint

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.

Practice

1. What is the main purpose of a startupProbe in Kubernetes?

easy

A. To monitor CPU and memory usage of the pod

B. To restart the pod immediately when it crashes

C. To check if the application has started before other health checks run

D. To manage network traffic routing to the pod

Solution

1. Step 1: Understand the role of startupProbe

   The startupProbe is designed to check if an application has started successfully before Kubernetes runs readiness or liveness probes.

2. Step 2: Differentiate from other probes

   Unlike liveness or readiness probes, startupProbe prevents Kubernetes from killing pods that take longer to start.

3. Final Answer:

   To check if the application has started before other health checks run -> Option C

4. Quick Check:

   startupProbe checks app start status = A [OK]

Hint: Startup probe delays other checks until app starts [OK]

Common Mistakes:

• Confusing startupProbe with livenessProbe
• Thinking startupProbe manages resource usage
• Assuming startupProbe handles traffic routing

2. Which of the following is the correct syntax to define a startupProbe using an HTTP GET request in a pod spec?

easy

A. startupProbe:
exec:
command: ["curl", "-f", "http://localhost:8080/healthz"]
timeoutSeconds: 5

B. startupProbe:
httpGet:
path: /healthz
port: 8080
failureThreshold: 30
periodSeconds: 10

C. startupProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 5

D. startupProbe:
httpGet:
path: /status
port: 80
successThreshold: 3

Solution

1. Step 1: Identify correct HTTP GET syntax for startupProbe

   The startupProbe uses httpGet with path and port fields, plus timing settings like failureThreshold and periodSeconds.

2. Step 2: Compare options for correctness

   startupProbe: httpGet: path: /healthz port: 8080 failureThreshold: 30 periodSeconds: 10 correctly uses httpGet with path /healthz, port 8080, and timing fields. Other options use exec or tcpSocket or wrong ports/fields.

3. Final Answer:

   startupProbe: httpGet: path: /healthz port: 8080 failureThreshold: 30 periodSeconds: 10 -> Option B

4. Quick Check:

   startupProbe HTTP GET with path and port = A [OK]

Hint: HTTP GET startupProbe needs path, port, failureThreshold [OK]

Common Mistakes:

• Using exec probe syntax instead of httpGet
• Missing failureThreshold or periodSeconds
• Incorrect port or path values

3. Given this pod spec snippet, what will happen if the startupProbe fails repeatedly during startup?

startupProbe:
  httpGet:
    path: /start
    port: 8080
  failureThreshold: 5
  periodSeconds: 2
livenessProbe:
  httpGet:
    path: /live
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5

medium

A. Kubernetes will never restart the pod because startupProbe is ignored

B. Kubernetes will restart the pod after 10 seconds of livenessProbe failures

C. Kubernetes will restart the pod after 10 seconds of readinessProbe failures

D. Kubernetes will restart the pod after 10 seconds of startupProbe failures

Solution

1. Step 1: Calculate startupProbe failure timeout

   failureThreshold 5 and periodSeconds 2 means Kubernetes waits 5*2=10 seconds of failed startupProbe checks before restarting.

2. Step 2: Understand probe precedence during startup

   During startup, startupProbe controls pod health. LivenessProbe starts after startupProbe succeeds, so restart depends on startupProbe failures first.

3. Final Answer:

   Kubernetes will restart the pod after 10 seconds of startupProbe failures -> Option D

4. Quick Check:

   startupProbe failureThreshold * periodSeconds = restart delay [OK]

Hint: Restart delay = failureThreshold x periodSeconds of startupProbe [OK]

Common Mistakes:

• Confusing startupProbe failure timing with livenessProbe
• Assuming readinessProbe triggers restart
• Ignoring startupProbe during pod startup

4. You configured a startupProbe but your pod keeps restarting immediately. Which fix is most likely correct?

medium

A. Increase failureThreshold and periodSeconds to allow more startup time

B. Remove the startupProbe to rely only on livenessProbe

C. Change the startupProbe to a readinessProbe

D. Set initialDelaySeconds to 0 in the livenessProbe

Solution

1. Step 1: Identify cause of immediate restarts

   If the startupProbe fails too quickly, Kubernetes restarts the pod before it finishes starting.

2. Step 2: Adjust startupProbe timing

   Increasing failureThreshold and periodSeconds gives the app more time to start before Kubernetes kills it.

3. Final Answer:

   Increase failureThreshold and periodSeconds to allow more startup time -> Option A

4. Quick Check:

   Longer startupProbe timeout prevents premature restarts [OK]

Hint: Longer failureThreshold and periodSeconds prevent early restarts [OK]

Common Mistakes:

• Removing startupProbe loses slow start protection
• Confusing startupProbe with readinessProbe
• Setting initialDelaySeconds on livenessProbe doesn't fix startup timing

5. You have a slow-starting app that takes about 3 minutes to initialize. How should you configure the startupProbe to avoid premature pod restarts?

hard

A. Set failureThreshold to 18 and periodSeconds to 10

B. Set failureThreshold to 3 and periodSeconds to 30

C. Set failureThreshold to 1 and periodSeconds to 100

D. Disable startupProbe and rely on livenessProbe with initialDelaySeconds 180

Solution

1. Step 1: Calculate total startupProbe timeout needed

   App needs 3 minutes (180 seconds) to start. Total timeout = failureThreshold x periodSeconds.

2. Step 2: Choose values matching 180 seconds

   Set failureThreshold to 18 and periodSeconds to 10: 18 x 10 = 180 seconds, allowing full startup time before restart.

3. Step 3: Evaluate other options

   Set failureThreshold to 1 and periodSeconds to 100: failureThreshold to 1 and periodSeconds to 100 = 100 seconds (too short). Set failureThreshold to 3 and periodSeconds to 30: 3 x 30 = 90 seconds (too short). Disable startupProbe and rely on livenessProbe with initialDelaySeconds 180 disables startupProbe, risking premature restarts from livenessProbe.

4. Final Answer:

   Set failureThreshold to 18 and periodSeconds to 10 -> Option A

5. Quick Check:

   failureThreshold x periodSeconds = startup timeout [OK]

Hint: Multiply failureThreshold by periodSeconds to match startup time [OK]

Common Mistakes:

• Configuring insufficient total timeout (failureThreshold x periodSeconds < 180s)
• Disabling startupProbe causing premature restarts
• Setting only initialDelaySeconds without startupProbe