Why probes keep applications healthy in Kubernetes - Challenge Your Understanding

Challenge - 5 Problems

🧠 Conceptual

intermediate

Purpose of Kubernetes Readiness Probe

What is the main purpose of a readiness probe in Kubernetes?

A To monitor the CPU and memory usage of the pod

B To restart the container if it crashes or becomes unresponsive

C To check if the application is ready to receive traffic and only then add it to the service endpoints

D To update the container image automatically when a new version is available

💡 Hint

Think about when Kubernetes should send traffic to a pod.

The readiness probe tells Kubernetes if the pod is ready to accept traffic. If the probe fails, Kubernetes stops sending requests to that pod until it passes again.

💻 Command Output

intermediate

Output of a Failing Liveness Probe

Given the following liveness probe configuration, what will Kubernetes do if the probe fails repeatedly?

Kubernetes

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10
  failureThreshold: 3

A Kubernetes will delete the pod permanently

B Kubernetes will stop sending traffic to the pod but will not restart it

C Kubernetes will ignore the failures and keep the container running

D Kubernetes will restart the container after 3 consecutive failures of the probe

💡 Hint

Remember what a liveness probe is designed to do.

The liveness probe checks if the container is alive. If it fails the configured number of times, Kubernetes restarts the container to try to fix the problem.

🔀 Workflow

advanced

Order of Probe Checks in Kubernetes

Arrange the following Kubernetes probe checks in the order they are typically performed during pod lifecycle:

A 1,2,3,4

B 2,1,4,3

C 2,3,1,4

D 3,2,1,4

💡 Hint

Think about what happens first when a pod starts and how traffic is routed.

The startup probe runs first to check if the app has started. Then readiness probe checks if it can receive traffic. If ready, pod is added to endpoints. Liveness probe runs continuously to check if app is alive.

❓ Troubleshoot

advanced

Troubleshooting a Pod Not Receiving Traffic

A pod is running but not receiving any traffic. The readiness probe is configured but the pod never becomes ready. What is the most likely cause?

A The readiness probe is failing, so Kubernetes does not add the pod to service endpoints

B The liveness probe is failing, causing the pod to restart repeatedly

C The pod has insufficient CPU resources and is throttled

D The container image is outdated and incompatible with the cluster

💡 Hint

Focus on what controls traffic routing to pods.

If the readiness probe fails, Kubernetes considers the pod not ready and excludes it from the service endpoints, so it won't receive traffic.

✅ Best Practice

expert

Best Practice for Using Startup Probes

Why is it recommended to use a startup probe for applications with long initialization times?

A To prevent Kubernetes from killing the container prematurely before it finishes starting

B To speed up the pod startup by skipping readiness checks

C To automatically scale the number of pods based on startup time

D To disable liveness and readiness probes during startup

💡 Hint

Think about what happens if liveness probes run too early on slow-starting apps.

Startup probes allow Kubernetes to wait longer for the app to start before running liveness probes. This avoids killing the container too soon.

Practice

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

easy

A. To check if the application is running and restart it if it is not healthy

B. To control when the application receives user traffic

C. To update the application configuration automatically

D. To monitor the CPU usage of the application

Solution

1. Step 1: Understand liveness probe role

   Liveness probes check if the app is alive and working properly.

2. Step 2: Identify action on failure

   If the liveness probe fails, Kubernetes restarts the app to fix it.

3. Final Answer:

   To check if the application is running and restart it if it is not healthy -> Option A

4. Quick Check:

   Liveness probe = restarts unhealthy app [OK]

Hint: Liveness probe restarts app if unhealthy [OK]

Common Mistakes:

• Confusing liveness with readiness probe
• Thinking liveness controls traffic
• Assuming liveness updates configs

2. Which of the following is the correct syntax to define a readiness probe in a Kubernetes pod spec?

easy

A. readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 10

B. livenessProbe:
exec:
command: ["curl", "/health"]
timeoutSeconds: 3

C. readinessProbe:
tcpSocket:
port: 80
failureThreshold: 5

D. startupProbe:
httpGet:
path: /start
port: 9090
periodSeconds: 15

Solution

1. Step 1: Identify readiness probe syntax

   Readiness probes often use httpGet with path and port defined.

2. Step 2: Match correct YAML structure

   readinessProbe: httpGet: path: /ready port: 8080 initialDelaySeconds: 5 periodSeconds: 10 shows readinessProbe with httpGet, initialDelaySeconds, and periodSeconds correctly.

3. Final Answer:

   readinessProbe: httpGet: path: /ready port: 8080 initialDelaySeconds: 5 periodSeconds: 10 -> Option A

4. Quick Check:

   Readiness probe syntax = readinessProbe: httpGet: path: /ready port: 8080 initialDelaySeconds: 5 periodSeconds: 10 [OK]

Hint: Readiness probe uses httpGet with path and port [OK]

Common Mistakes:

• Mixing liveness and readiness probe syntax
• Using startupProbe instead of readinessProbe
• Incorrect indentation or missing fields

3. Given this pod spec snippet, what happens if the readiness probe fails?

readinessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10

medium

A. The pod is restarted immediately

B. The pod stops receiving new traffic but keeps running

C. The pod is deleted from the cluster

D. Nothing happens; the pod continues as normal

Solution

1. Step 1: Understand readiness probe effect

   Readiness probe controls if pod is ready to get user traffic.

2. Step 2: Identify behavior on failure

   If readiness probe fails, pod stays running but is removed from service endpoints, so no new traffic.

3. Final Answer:

   The pod stops receiving new traffic but keeps running -> Option B

4. Quick Check:

   Readiness failure = no traffic, pod runs [OK]

Hint: Readiness failure stops traffic, no restart [OK]

Common Mistakes:

• Thinking readiness failure restarts pod
• Confusing readiness with liveness probe
• Assuming pod deletion on readiness failure

4. You notice your application pod keeps restarting frequently. The liveness probe is defined as:

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10
  failureThreshold: 3

What is the most likely cause?

medium

A. The readiness probe is missing

B. The liveness probe is incorrectly configured with wrong port

C. The pod has insufficient CPU resources

D. The application is not responding to the /health endpoint in time

Solution

1. Step 1: Analyze liveness probe behavior

   Liveness probe checks /health on port 8080 every 10 seconds after 5 seconds delay.

2. Step 2: Understand restart cause

   If app does not respond correctly 3 times (failureThreshold), Kubernetes restarts pod.

3. Final Answer:

   The application is not responding to the /health endpoint in time -> Option D

4. Quick Check:

   Liveness failure = app not responding, causes restart [OK]

Hint: Liveness failure causes restart due to no response [OK]

Common Mistakes:

• Assuming readiness probe causes restart
• Ignoring failureThreshold effect
• Blaming resource limits without evidence

5. You want to ensure your app only receives traffic after it finishes loading data and is ready. Which probe setup achieves this best?

hard

A. Use a startup probe that immediately sends traffic to the app

B. Use a liveness probe that restarts the app if /health fails

C. Use a readiness probe that checks a /ready endpoint returning success after data load

D. Use both liveness and readiness probes checking the same /health endpoint

Solution

1. Step 1: Identify probe controlling traffic

   Readiness probe controls when app receives user traffic.

2. Step 2: Choose probe matching app readiness

   Readiness probe checking /ready after data load ensures traffic only after app is ready.

3. Step 3: Exclude other options

   Liveness restarts app but does not control traffic; startup probe delays startup but not traffic control.

4. Final Answer:

   Use a readiness probe that checks a /ready endpoint returning success after data load -> Option C

5. Quick Check:

   Readiness probe controls traffic flow [OK]

Hint: Readiness probe controls traffic after app is ready [OK]

Common Mistakes:

• Using liveness probe to control traffic
• Confusing startup probe with readiness probe
• Checking same endpoint for both probes