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.