Liveness probe concept in Kubernetes - Commands & Configuration

Introduction

Sometimes, applications inside containers can stop working but still appear running. A liveness probe helps Kubernetes check if an app is alive and restart it if it is stuck or crashed.

When your app might freeze or get stuck and needs a restart to recover.

When you want Kubernetes to automatically fix apps that stop responding.

When running long-lived services that must stay healthy without manual checks.

When you want to avoid manual intervention for crashed or deadlocked containers.

When you want to improve app reliability by automatic self-healing.

Config File - pod.yaml

pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: liveness-demo
spec:
  containers:
  - name: my-app
    image: nginx:1.23
    livenessProbe:
      httpGet:
        path: /healthz
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 10
      timeoutSeconds: 1
      failureThreshold: 3

This file creates a pod named liveness-demo running an Nginx container.

The livenessProbe section tells Kubernetes to check the /healthz URL on port 80 every 10 seconds, starting 5 seconds after the container starts.

If the check fails, Kubernetes restarts the container automatically.

Commands

This command creates the pod with the liveness probe defined. Kubernetes will start the container and begin health checks.

Terminal

kubectl apply -f pod.yaml

Expected Output

pod/liveness-demo created

This command shows the status of all pods, including our new pod, to verify it is running.

Terminal

kubectl get pods

Expected Output

NAME           READY   STATUS    RESTARTS   AGE

liveness-demo  1/1     Running   0          10s

This command shows detailed information about the pod, including events related to the liveness probe and any restarts.

Terminal

kubectl describe pod liveness-demo

Expected Output

Name:         liveness-demo

Namespace:    default

Containers:

  my-app:

    Container ID:   docker://abcdef123456

    Image:          nginx:1.23

    State:          Running

    Ready:          True

    Restart Count:  0

    Liveness:       http-get http://:80/healthz delay=5s timeout=1s period=10s #success=1 #failure=3

Events:

  Type    Reason     Age   From               Message

  ----    ------     ----  ----               -------

  Normal  Scheduled  1m    default-scheduler  Successfully assigned default/liveness-demo to node-1

Key Concept

If you remember nothing else from this pattern, remember: a liveness probe lets Kubernetes detect and fix stuck or crashed containers automatically by restarting them.

Common Mistakes

Not setting initialDelaySeconds causing the probe to run before the app is ready

The probe fails immediately and Kubernetes restarts the container repeatedly, causing a crash loop.

Set initialDelaySeconds to a value that gives your app time to start before health checks begin.

Using a wrong path or port in the httpGet probe

The probe always fails because it cannot reach the correct endpoint, causing unnecessary restarts.

Verify the path and port match your app's health endpoint exactly.

Confusing livenessProbe with readinessProbe

Liveness restarts the container; readiness controls traffic routing. Using the wrong probe can cause unwanted restarts or traffic issues.

Use livenessProbe to check if the app is alive and restart if needed; use readinessProbe to control if the pod receives traffic.

Summary

Define a liveness probe in your pod spec to let Kubernetes check if your app is alive.

Use kubectl apply to create the pod and kubectl get pods to verify it is running.

Use kubectl describe pod to see detailed probe status and container restarts.

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