HTTP probe configuration in Kubernetes - Step-by-Step Execution

Process Flow - HTTP probe configuration

Pod starts

↓

Kubelet sets HTTP probe

↓

Send HTTP GET request to container endpoint

↓

Check HTTP response code

↓

Probe success

↓

Pod ready

The kubelet sends HTTP GET requests to the container's endpoint to check health. If the response is 200-399, the probe succeeds; otherwise, it fails.

Execution Sample

Kubernetes

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

This config checks the /healthz path on port 8080 every 10 seconds after an initial delay of 5 seconds.

Process Table

Step	Action	HTTP Request Sent	Response Code	Probe Result	Pod State
1	Wait initialDelaySeconds	No	N/A	No probe yet	Pod starting
2	Send HTTP GET /healthz:8080	GET /healthz:8080	200	Success	Pod ready
3	Wait periodSeconds	No	N/A	No probe yet	Pod ready
4	Send HTTP GET /healthz:8080	GET /healthz:8080	500	Failure	Pod marked unhealthy
5	Kubelet restarts container	No	N/A	Probe reset	Pod restarting
6	Wait initialDelaySeconds	No	N/A	No probe yet	Pod restarting
7	Send HTTP GET /healthz:8080	GET /healthz:8080	200	Success	Pod ready

💡 Probe cycles continue; pod state changes based on probe success or failure.

Status Tracker

Variable	Start	After Step 2	After Step 4	After Step 7
Pod State	Starting	Ready	Unhealthy	Ready
Probe Result	None	Success	Failure	Success
HTTP Response Code	None	200	500	200

Key Moments - 3 Insights

Why does the pod become 'Unhealthy' at step 4 even though it was 'Ready' at step 2?

Because at step 4 the HTTP response code was 500, which is outside the 200-399 success range, causing the probe to fail and pod to be marked unhealthy (see execution_table row 4).

What is the purpose of initialDelaySeconds before the first probe?

It gives the container time to start before probes begin, preventing false failures early on (see execution_table step 1 and 6 where no probe is sent).

What happens after a probe failure is detected?

The kubelet restarts the container or marks it not ready to recover from failure (see execution_table step 5).

Visual Quiz - 3 Questions

Look at the execution table, what is the Pod State after the first successful probe?

A Ready

B Unhealthy

C Starting

D Restarting

💡 Hint

Check the Pod State column at step 2 in the execution_table.

At which step does the HTTP probe detect failure?

A Step 2

B Step 4

C Step 6

D Step 7

💡 Hint

Look at the Probe Result and Response Code columns in execution_table.

If initialDelaySeconds was set to 0, how would the execution table change?

A HTTP requests would be sent after 10 seconds

B Pod would never become ready

C Probe would start immediately at step 1

D Pod would skip the probe

💡 Hint

initialDelaySeconds controls when the first probe is sent; see step 1 and 6.

Concept Snapshot

HTTP Probe Configuration in Kubernetes:
- Uses httpGet to check container health via HTTP GET requests.
- Configurable path, port, initialDelaySeconds, periodSeconds.
- Success if HTTP status 200-399, failure otherwise.
- Failure triggers pod restart or marking pod unhealthy.
- Helps Kubernetes manage pod lifecycle automatically.

Full Transcript

In Kubernetes, an HTTP probe is a health check where the kubelet sends HTTP GET requests to a container's endpoint. The probe configuration includes the path and port to check, plus timing settings like initialDelaySeconds and periodSeconds. When the pod starts, kubelet waits initialDelaySeconds before sending the first HTTP request. If the response code is between 200 and 399, the probe succeeds and the pod is marked ready. If the response is outside this range, the probe fails, and Kubernetes may restart the container or mark the pod unhealthy. This cycle repeats periodically to ensure the pod stays healthy. The execution table shows these steps with pod state changes and probe results. Key points include the importance of initialDelaySeconds to avoid false failures and how probe failures trigger restarts.

Practice

1. What is the main purpose of an HTTP probe in Kubernetes?

easy

A. To deploy new versions of the application automatically

B. To store application logs for debugging

C. To check if the application is running and responding to HTTP requests

D. To manage network traffic between pods

Solution

1. Step 1: Understand the role of HTTP probes

   HTTP probes send HTTP requests to the app to check if it is alive and ready.

2. Step 2: Identify the correct purpose

   Only To check if the application is running and responding to HTTP requests describes checking app health via HTTP requests.

3. Final Answer:

   To check if the application is running and responding to HTTP requests -> Option C

4. Quick Check:

   HTTP probe purpose = health check [OK]

Hint: HTTP probes test app health by sending HTTP requests [OK]

Common Mistakes:

• Confusing probes with deployment or logging
• Thinking probes manage network traffic
• Assuming probes store logs

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

easy

A. livenessProbe:
exec:
command: ["curl", "/healthz"]
initialDelaySeconds: 5
periodSeconds: 10

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

C. livenessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 5
periodSeconds: 10

D. livenessProbe:
httpGet:
url: http://localhost:8080/healthz
initialDelaySeconds: 5
periodSeconds: 10

Solution

1. Step 1: Review HTTP probe syntax

   The correct HTTP probe uses httpGet with path and port keys.

2. Step 2: Identify the correct YAML structure

   livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 5 periodSeconds: 10 correctly uses httpGet with path and port. livenessProbe: httpGet: url: http://localhost:8080/healthz initialDelaySeconds: 5 periodSeconds: 10 is invalid because url is not a valid key.

3. Final Answer:

   Correct HTTP liveness probe syntax with httpGet, path, and port -> Option B

4. Quick Check:

   httpGet uses path and port keys [OK]

Hint: Use httpGet with path and port, not url [OK]

Common Mistakes:

• Using 'url' instead of 'path' in httpGet
• Confusing exec or tcpSocket probes with httpGet
• Wrong indentation or missing keys

3. Given this probe configuration snippet in a pod spec:

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

What will Kubernetes do after the pod starts?

medium

A. Send an HTTP GET to /status only once after 10 seconds

B. Send an HTTP GET to /status immediately, then every 10 seconds

C. Wait 5 seconds, then send an HTTP GET to /status every 10 seconds

D. Wait 10 seconds, then send an HTTP GET to /status every 5 seconds

Solution

1. Step 1: Understand initialDelaySeconds

   This value tells Kubernetes to wait 10 seconds after pod start before first probe.

2. Step 2: Understand periodSeconds

   This value sets the interval between probes, here every 5 seconds.

3. Final Answer:

   Wait 10 seconds, then send an HTTP GET to /status every 5 seconds -> Option D

4. Quick Check:

   initialDelaySeconds = wait, periodSeconds = repeat interval [OK]

Hint: initialDelaySeconds = wait before first probe, periodSeconds = probe interval [OK]

Common Mistakes:

• Confusing initialDelaySeconds with periodSeconds
• Assuming immediate probe on pod start
• Mixing up timing values

4. You configured this HTTP readiness probe:

readinessProbe:
  httpGet:
    path: /ready
    port: 80
  initialDelaySeconds: 5
  periodSeconds: 10
  timeoutSeconds: 2

But Kubernetes marks the pod as not ready even though the app is healthy. What is the likely problem?

medium

A. The probe path /ready is incorrect or not handled by the app

B. initialDelaySeconds is too high, delaying readiness

C. timeoutSeconds is too long, causing probe to fail

D. periodSeconds is too short, causing probe overload

Solution

1. Step 1: Check probe path correctness

   If the app does not respond correctly to /ready, probe fails and pod is not ready.

2. Step 2: Evaluate timing parameters

   initialDelaySeconds of 5 is reasonable; timeoutSeconds of 2 is short but typical; periodSeconds of 10 is normal.

3. Final Answer:

   The probe path /ready is incorrect or not handled by the app -> Option A

4. Quick Check:

   Probe path must match app endpoint [OK]

Hint: Check if probe path matches app endpoint exactly [OK]

Common Mistakes:

• Ignoring probe path correctness
• Changing timing values unnecessarily
• Assuming timeoutSeconds causes readiness failure

5. You want to configure a Kubernetes HTTP readiness probe that waits 15 seconds after container start, then checks the path /health every 3 seconds, but fails the pod if no response within 1 second. Which is the correct probe configuration snippet?

hard

A. readinessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 15
periodSeconds: 3
timeoutSeconds: 1

B. readinessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 3
periodSeconds: 15
timeoutSeconds: 1

C. readinessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 15
periodSeconds: 1
timeoutSeconds: 3

D. readinessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 1
periodSeconds: 15
timeoutSeconds: 3

Solution

1. Step 1: Match initialDelaySeconds to 15 seconds

   The probe must wait 15 seconds before first check, so initialDelaySeconds: 15.

2. Step 2: Set periodSeconds to 3 seconds and timeoutSeconds to 1 second

   Checks happen every 3 seconds, and timeout is 1 second as required.

3. Final Answer:

   Correct probe with initialDelaySeconds 15, periodSeconds 3, timeoutSeconds 1 -> Option A

4. Quick Check:

   initialDelay=15, period=3, timeout=1 matches requirements [OK]

Hint: Match timing values exactly to requirements [OK]

Common Mistakes:

• Swapping initialDelaySeconds and periodSeconds
• Setting timeoutSeconds longer than periodSeconds
• Using wrong path or port