Why probes keep applications healthy in Kubernetes - Visual Breakdown

Process Flow - Why probes keep applications healthy

Start Application Pod

↓

Kubelet runs Probes

↓

Perform Liveness Probe

↓

Is Pod Alive?

No→Restart Pod

Yes↓

Perform Readiness Probe

↓

Is Pod Ready?

No→Remove Pod from Service

Yes↓

Pod serves traffic

↓

Repeat Probes Periodically

Kubernetes uses probes to check if an application is alive and ready. If not alive, it restarts the pod. If not ready, it stops sending traffic to it.

Execution Sample

Kubernetes

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

This liveness probe checks the /healthz endpoint every 10 seconds after waiting 5 seconds initially.

Process Table

Step	Probe Type	Probe Action	Probe Result	Kubelet Action	Pod State
1	Liveness	Check /healthz	Success	No action	Running
2	Readiness	Check /ready	Success	Pod in service	Serving traffic
3	Liveness	Check /healthz	Failure	Restart Pod	Restarting
4	Liveness	Check /healthz	Success	No action	Running
5	Readiness	Check /ready	Failure	Remove from service	Not serving traffic
6	Readiness	Check /ready	Success	Add to service	Serving traffic
7	Liveness	Check /healthz	Success	No action	Running

💡 Probes run continuously to keep pod healthy and traffic routed correctly.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5	After Step 6	After Step 7
Pod State	Starting	Running	Serving traffic	Restarting	Running	Not serving traffic	Serving traffic	Running
Traffic Routing	None	Routed	Routed	None	None	None	Routed	Routed

Key Moments - 3 Insights

Why does the pod restart after a liveness probe failure?

Because the liveness probe failure means the pod is unhealthy and cannot recover, so Kubernetes restarts it to restore health (see execution_table step 3).

Why is traffic removed from the pod after a readiness probe failure?

Readiness probe failure means the pod is not ready to serve requests, so Kubernetes stops sending traffic to avoid errors (see execution_table step 5).

Can a pod be running but not serving traffic?

Yes, if the readiness probe fails but liveness probe passes, the pod runs but is removed from service (see execution_table step 5).

Visual Quiz - 3 Questions

Look at the execution_table, what action does Kubernetes take at step 3 when the liveness probe fails?

A Restart the pod

B Remove pod from service

C Do nothing

D Send traffic to pod

💡 Hint

Check the 'Kubelet Action' column at step 3 in the execution_table.

At which step does the pod stop serving traffic due to readiness probe failure?

A Step 2

B Step 4

C Step 5

D Step 7

💡 Hint

Look at the 'Pod State' and 'Kubelet Action' columns for readiness probe failures.

If the readiness probe always succeeds, how would the traffic routing change in the variable_tracker?

A Traffic would never be routed

B Traffic would always be routed to the pod

C Traffic would be removed intermittently

D Pod would restart frequently

💡 Hint

Check the 'Traffic Routing' row in variable_tracker and relate it to readiness probe results.

Concept Snapshot

Kubernetes probes check pod health:
- Liveness probe: restarts pod if unhealthy
- Readiness probe: controls traffic routing
- Probes run periodically
- Keeps apps healthy and responsive

Full Transcript

Kubernetes uses liveness and readiness probes to keep applications healthy. The liveness probe checks if the pod is alive; if it fails, Kubernetes restarts the pod to fix issues. The readiness probe checks if the pod is ready to serve traffic; if it fails, Kubernetes stops sending traffic to avoid errors. These probes run repeatedly to monitor pod health and traffic routing. This process ensures applications stay healthy and responsive.

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