What are Kubernetes Liveness and Readiness Probes?
Learn the difference between Kubernetes liveness and readiness probes, how startupProbe works, and how they enable self-healing.
Expected Interview Answer
A liveness probe tells Kubernetes whether a container is still healthy and should keep running — failing it triggers a container restart — while a readiness probe tells Kubernetes whether a container is currently able to accept traffic, and failing it removes the Pod from Service endpoints without restarting anything.
Both probes can be implemented as an HTTP GET request expecting a 2xx/3xx status, a TCP socket check, or a command executed inside the container, and both are configured with `initialDelaySeconds`, `periodSeconds`, `timeoutSeconds`, and `failureThreshold` to control timing and sensitivity. A liveness probe answers “is this container stuck or deadlocked?” — if it fails repeatedly past the failure threshold, the kubelet kills and restarts the container in place, which is the self-healing mechanism for hung processes that are still technically running but no longer functioning. A readiness probe answers “can this container serve requests right now?” — a Pod that fails readiness is instantly pulled out of the Service’s load-balancing rotation (its endpoint is removed) without being restarted, which is essential during slow startup (loading a large model or warming a cache) or temporary overload, so traffic is not sent to a Pod that cannot yet handle it. A third probe type, `startupProbe`, delays liveness/readiness checks until a slow-starting container has finished initializing, preventing premature restarts during a long boot sequence.
- Liveness probes automatically restart hung or deadlocked containers
- Readiness probes stop traffic from reaching a Pod that is not ready yet
- startupProbe protects slow-starting containers from premature restarts
- Together they enable self-healing and safe rolling updates without downtime
AI Mentor Explanation
A liveness probe is like a team doctor periodically checking if a player on the field has been knocked unconscious — if the player fails to respond repeatedly, they are pulled off and a substitute is sent on to restart in that role. A readiness probe is like a fitness check before each session asking whether a recovering player is match-fit today — if not fit, they simply sit out that match without being removed from the squad, and rejoin once fit again. The doctor’s check is about survival; the fitness check is about current availability to play.
Step-by-Step Explanation
Step 1
Define a livenessProbe
Configure an httpGet, tcpSocket, or exec check with initialDelaySeconds and failureThreshold.
Step 2
Define a readinessProbe
Add a similar check that governs whether the Pod receives traffic via the Service endpoint list.
Step 3
Optionally add startupProbe
For slow-starting containers, delay liveness/readiness checks until startupProbe succeeds.
Step 4
Kubernetes acts on results
Liveness failure restarts the container; readiness failure removes the Pod from Service endpoints without restarting.
What Interviewer Expects
- Clear distinction: liveness restarts, readiness only removes from traffic
- Knowledge of probe types: httpGet, tcpSocket, exec
- Understanding of timing fields: initialDelaySeconds, periodSeconds, failureThreshold
- Awareness of startupProbe for slow-starting containers
Common Mistakes
- Using the same overly strict check for both liveness and readiness, causing restart loops
- Setting initialDelaySeconds too low for a slow-starting app, causing premature restarts
- Believing a failed readiness probe restarts the container (it does not)
- Forgetting startupProbe exists for apps with long initialization time
Best Answer (HR Friendly)
“A liveness probe is Kubernetes asking “is this container still alive and working?” — if it stops responding, Kubernetes restarts it automatically. A readiness probe is Kubernetes asking “is this container ready to handle traffic right now?” — if not, it just gets temporarily pulled out of rotation so users are not sent to a Pod that is still starting up or overloaded, without anything being restarted.”
Code Example
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
spec:
containers:
- name: app
image: myapp:1.0
ports:
- containerPort: 8080
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 15
periodSeconds: 10
failureThreshold: 3
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
failureThreshold: 2Follow-up Questions
- What is the difference between a startupProbe and an initialDelaySeconds setting?
- What happens to Service traffic when a readiness probe fails?
- How would you design a liveness check to avoid false-positive restarts?
- Can a container be alive but not ready, and why does that matter?
MCQ Practice
1. What action does Kubernetes take when a liveness probe fails repeatedly?
A failing liveness probe past the failure threshold causes the kubelet to restart the container in place.
2. What happens when a readiness probe fails?
A failed readiness probe pulls the Pod out of load-balancing rotation without restarting the container.
3. Why does startupProbe exist alongside liveness and readiness probes?
startupProbe prevents premature liveness restarts by giving slow-starting containers extra time before other probes begin.
Flash Cards
What does a liveness probe do? — Checks if a container is healthy; failure triggers a restart.
What does a readiness probe do? — Checks if a container can serve traffic; failure removes it from Service endpoints without restarting.
What does startupProbe protect against? — Premature liveness/readiness restarts during a slow container startup.
What probe check types exist? — httpGet, tcpSocket, and exec command checks.