Liveness probe concept in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

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

Choose the best description of what a liveness probe does in a Kubernetes pod.

A It controls the network traffic routing to the pod.

B It monitors the CPU usage of the pod and scales it up if usage is high.

C It checks if the pod is running and restarts it if it is not responding.

D It verifies if the pod has enough memory to continue running.

💡 Hint

Think about what happens when a pod becomes unresponsive or stuck.

A liveness probe checks if the pod is alive and responsive. If the probe fails, Kubernetes restarts the pod to recover it.

💻 Command Output

intermediate

What is the output when a liveness probe fails repeatedly?

Given a pod with a liveness probe configured, what happens if the probe fails 3 times in a row?

A The pod is deleted permanently and not restarted.

B The pod is restarted by Kubernetes automatically.

C The pod continues running but logs an error message.

D The pod is scaled down to zero replicas.

💡 Hint

Consider Kubernetes behavior on failing health checks.

When a liveness probe fails the configured number of times, Kubernetes restarts the pod to try to fix the issue.

❓ Configuration

advanced

Identify the correct liveness probe configuration snippet

Which YAML snippet correctly configures an HTTP liveness probe on path /healthz with a 5-second initial delay?

A

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

B

livenessProbe:
  exec:
    command: ["curl", "-f", "http://localhost:8080/healthz"]
  initialDelaySeconds: 5

C

livenessProbe:
  tcpSocket:
    port: 8080
  initialDelaySeconds: 5
  timeoutSeconds: 1

D

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

💡 Hint

Look for the HTTP GET probe with correct path and initial delay.

Option A correctly sets an HTTP GET liveness probe on /healthz with a 5-second initial delay and a 10-second period.

❓ Troubleshoot

advanced

Why does a pod keep restarting despite a working liveness probe?

A pod configured with a liveness probe keeps restarting even though the probe command returns success. What could be a likely cause?

A The pod has insufficient CPU resources allocated.

B The readiness probe is misconfigured, blocking traffic.

C The liveness probe timeout is too short, causing false failures.

D The pod's application is crashing due to internal errors unrelated to the probe.

💡 Hint

Think about causes of pod restarts beyond probe failures.

If the application inside the pod crashes, Kubernetes restarts the pod regardless of the liveness probe status.

✅ Best Practice

expert

What is the recommended approach to avoid false positives in liveness probes?

Which practice helps prevent Kubernetes from restarting pods unnecessarily due to transient issues in liveness probes?

A Set a reasonable <code>initialDelaySeconds</code> and <code>failureThreshold</code> to allow startup and transient failures.

B Configure the liveness probe to run every second for quick detection.

C Use only TCP socket probes as they are faster than HTTP or exec probes.

D Disable liveness probes and rely on manual pod restarts.

💡 Hint

Consider how to give the pod time to start and recover before restarting.

Setting initialDelaySeconds and increasing failureThreshold helps avoid restarts caused by slow startups or temporary glitches.