Liveness probe concept in Kubernetes - Step-by-Step Execution

Process Flow - Liveness probe concept

Pod starts running

↓

Kubelet sends liveness probe

↓

Probe checks container health

↓

Healthy?

Yes→Wait for next probe

No↓

Kubelet kills container

↓

Container restarts

↩Back to sending liveness probe

The liveness probe checks if a container is alive. If not, Kubernetes restarts it to keep the app healthy.

Execution Sample

Kubernetes

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

This YAML config tells Kubernetes to check the /healthz URL on port 8080 every 10 seconds after waiting 5 seconds initially.

Process Table

Step	Action	Probe Result	Kubelet Decision	Container State
1	Pod starts, wait 5 seconds	No probe yet	Wait	Running
2	Send liveness probe (GET /healthz)	Success (200 OK)	Do nothing	Running
3	Wait 10 seconds	No probe	Wait	Running
4	Send liveness probe (GET /healthz)	Failure (timeout)	Kill container	Terminating
5	Container restarts	No probe yet	Wait	Starting
6	Send liveness probe (GET /healthz)	Success (200 OK)	Do nothing	Running

💡 Container is healthy again, so liveness probes continue periodically.

Status Tracker

Variable	Start	After Step 2	After Step 4	After Step 5	After Step 6
Container State	Running	Running	Terminating	Starting	Running
Probe Result	None	Success	Failure	None	Success

Key Moments - 3 Insights

Why does Kubernetes kill the container after a failed liveness probe?

Because the liveness probe failure means the container is unhealthy or stuck, so Kubernetes restarts it to fix the problem (see execution_table step 4).

What happens during the initialDelaySeconds period?

Kubernetes waits before sending the first liveness probe to give the container time to start up (see execution_table step 1).

Does a successful liveness probe restart the container?

No, a successful probe means the container is healthy, so Kubernetes does nothing and continues monitoring (see execution_table step 2 and 6).

Visual Quiz - 3 Questions

Look at the execution table, what is the container state after step 4?

A Running

B Terminating

C Starting

D Stopped

💡 Hint

Check the 'Container State' column at step 4 in the execution_table.

At which step does Kubernetes restart the container?

A Step 4

B Step 3

C Step 5

D Step 2

💡 Hint

Look for the step where the container state changes to 'Starting' in the execution_table.

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

A Step 1 would send a probe immediately

B Container would never restart

C Probe results would always be failure

D Container state would start as Terminating

💡 Hint

Refer to the description of initialDelaySeconds and step 1 in the execution_table.

Concept Snapshot

Liveness Probe in Kubernetes:
- Checks if container is alive
- Configured with httpGet, tcpSocket, or exec
- initialDelaySeconds waits before first check
- periodSeconds sets check frequency
- Failure causes container restart
- Keeps app healthy automatically

Full Transcript

A liveness probe is a health check Kubernetes uses to see if a container is alive. When a pod starts, Kubernetes waits for initialDelaySeconds before sending the first probe. It then sends probes every periodSeconds. If the probe succeeds, Kubernetes does nothing and waits for the next check. If the probe fails, Kubernetes kills the container and restarts it. This cycle repeats to keep the application running smoothly. The YAML example shows a simple HTTP GET probe on /healthz at port 8080. The execution table traces the container state and probe results step-by-step, showing how Kubernetes reacts to success and failure. Key points include the wait before the first probe, the restart on failure, and no action on success. This helps beginners understand how liveness probes maintain container health automatically.

Practice

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

easy

A. To check if a container is alive and restart it if it is not

B. To check if a container is ready to accept traffic

C. To monitor the CPU usage of a container

D. To scale the number of pods automatically

Solution

1. Step 1: Understand the role of liveness probes

   Liveness probes check if a container is still running properly. If not, Kubernetes restarts it to fix issues.

2. Step 2: Differentiate from readiness probes

   Readiness probes check if a container can receive traffic, but liveness probes focus on container health and restarting.

3. Final Answer:

   To check if a container is alive and restart it if it is not -> Option A

4. Quick Check:

   Liveness probe = container health check and restart [OK]

Hint: Liveness probes restart unhealthy containers automatically [OK]

Common Mistakes:

• Confusing liveness probe with readiness probe
• Thinking it scales pods instead of restarting
• Assuming it monitors resource usage

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

easy

A. "livenessProbe:\n httpGet:\n path: /healthz\n port: 8080\n initialDelaySeconds: 5"

B. "livenessProbe:\n exec:\n command: [\"curl\", \"/healthz\"]\n initialDelaySeconds: 5"

C. "livenessProbe:\n tcpSocket:\n path: /healthz\n port: 8080\n initialDelaySeconds: 5"

D. "livenessProbe:\n httpGet:\n path: healthz\n port: 'eighty'\n initialDelaySeconds: 5"

Solution

1. Step 1: Check HTTP GET syntax for livenessProbe

   The correct syntax uses httpGet with path and numeric port. "livenessProbe:\n httpGet:\n path: /healthz\n port: 8080\n initialDelaySeconds: 5" matches this.

2. Step 2: Identify errors in other options

   "livenessProbe:\n exec:\n command: [\"curl\", \"/healthz\"]\n initialDelaySeconds: 5" uses exec with curl incorrectly. "livenessProbe:\n tcpSocket:\n path: /healthz\n port: 8080\n initialDelaySeconds: 5" wrongly uses tcpSocket with a path. "livenessProbe:\n httpGet:\n path: healthz\n port: 'eighty'\n initialDelaySeconds: 5" uses a string for port instead of a number.

3. Final Answer:

   "livenessProbe:\n httpGet:\n path: /healthz\n port: 8080\n initialDelaySeconds: 5" -> Option A

4. Quick Check:

   HTTP GET probe syntax = "livenessProbe:\n httpGet:\n path: /healthz\n port: 8080\n initialDelaySeconds: 5" [OK]

Hint: HTTP GET needs numeric port and valid path [OK]

Common Mistakes:

• Using string instead of number for port
• Adding path to tcpSocket probe
• Using exec command incorrectly

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

livenessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy
  initialDelaySeconds: 3
  periodSeconds: 3

What happens if the file /tmp/healthy is deleted inside the container?

medium

A. The container will continue running without restart

B. The container will be restarted by Kubernetes

C. The pod will be deleted permanently

D. The liveness probe will be ignored

Solution

1. Step 1: Understand exec liveness probe behavior

   The exec probe runs the command. If the command fails (non-zero exit), Kubernetes restarts the container.

2. Step 2: Effect of deleting /tmp/healthy file

   Without the file, cat /tmp/healthy fails, so the probe fails and triggers a restart.

3. Final Answer:

   The container will be restarted by Kubernetes -> Option B

4. Quick Check:

   Exec probe fails = container restart [OK]

Hint: Exec probe failure restarts container [OK]

Common Mistakes:

• Thinking pod is deleted permanently
• Assuming probe failure is ignored
• Confusing liveness with readiness probe

4. You configured a liveness probe with this snippet:

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

But your container keeps restarting even though the app is healthy. What is the most likely cause?

medium

A. The port number 80 is invalid

B. The initialDelaySeconds is too high

C. The probe path /health is incorrect or not responding

D. The failureThreshold is set too high

Solution

1. Step 1: Analyze probe failure reasons

   If the probe path is wrong or the app does not respond at /health, the probe fails and restarts the container.

2. Step 2: Check other parameters

   Initial delay of 10 seconds is usually enough. Failure threshold of 3 means 3 failures before restart, which is normal. Port 80 is valid.

3. Final Answer:

   The probe path /health is incorrect or not responding -> Option C

4. Quick Check:

   Wrong probe path causes restarts [OK]

Hint: Check probe URL path correctness first [OK]

Common Mistakes:

• Changing initialDelaySeconds unnecessarily
• Misunderstanding failureThreshold effect
• Assuming port 80 is invalid

5. You want to create a liveness probe that checks a TCP port 3306 on your container every 10 seconds, but only start checking after 30 seconds from container start. Which is the correct configuration snippet?

hard

A. "livenessProbe:\n tcpSocket:\n port: '3306'\n initialDelaySeconds: 10\n periodSeconds: 30"

B. "livenessProbe:\n httpGet:\n path: /\n port: 3306\n initialDelaySeconds: 10\n periodSeconds: 30"

C. "livenessProbe:\n exec:\n command: [\"nc\", \"-z\", \"localhost\", \"3306\"]\n initialDelaySeconds: 30\n periodSeconds: 10"

D. "livenessProbe:\n tcpSocket:\n port: 3306\n initialDelaySeconds: 30\n periodSeconds: 10"

Solution

1. Step 1: Identify TCP socket probe syntax

   The tcpSocket probe uses port as a number, with initialDelaySeconds and periodSeconds set as required. "livenessProbe:\n tcpSocket:\n port: 3306\n initialDelaySeconds: 30\n periodSeconds: 10" matches this.

2. Step 2: Check timing and port correctness

   "livenessProbe:\n tcpSocket:\n port: 3306\n initialDelaySeconds: 30\n periodSeconds: 10" sets initial delay to 30 seconds and period to 10 seconds, matching the requirement. Other options have wrong timing or use HTTP or exec probes incorrectly.

3. Final Answer:

   "livenessProbe:\n tcpSocket:\n port: 3306\n initialDelaySeconds: 30\n periodSeconds: 10" -> Option D

4. Quick Check:

   TCP probe with correct timing = "livenessProbe:\n tcpSocket:\n port: 3306\n initialDelaySeconds: 30\n periodSeconds: 10" [OK]

Hint: TCP probe uses numeric port and correct delays [OK]

Common Mistakes:

• Using string instead of number for port
• Mixing HTTP probe for TCP check
• Setting wrong initialDelaySeconds or periodSeconds