How do liveness, readiness, and startup probes differ in Kubernetes?
Understand how Kubernetes liveness, readiness, and startup probes differ, what action each triggers, and how to configure them for self-healing apps.
Expected Interview Answer
A liveness probe checks if a container is still healthy and restarts it if not, a readiness probe checks if a container is ready to receive traffic and removes it from Service endpoints if not, and a startup probe protects slow-starting apps by delaying the other probes until the app has booted.
All three run periodically inside the kubelet and support the same handlers: HTTP GET, TCP socket, exec command, and gRPC. The distinction is the action each drives. Failing liveness restarts the container; failing readiness only stops traffic without a restart; while a startup probe is running, liveness and readiness are held off, so a heavy application is not killed before it finishes initializing.
- Automatic recovery from deadlocked containers
- Traffic only reaches ready Pods
- Slow-starting apps avoid premature restart loops
- Zero-downtime rollouts and reliable scaling
- Self-healing without manual intervention
AI Mentor Explanation
A startup probe is the warm-up before play — nobody judges the bowler until nets are done. Readiness is the umpire signalling a fielder is in position before the ball is bowled; if not ready, play pauses for him. Liveness is the physio deciding an injured player must be substituted off entirely. Each check triggers a different action: wait, hold traffic, or replace.
Step-by-Step Explanation
Step 1
Add a startup probe for slow apps
Define a startup probe with generous failureThreshold so heavy initialization completes before other probes run.
Step 2
Configure liveness
Point liveness at a lightweight health endpoint; failure restarts the container to recover from deadlocks.
Step 3
Configure readiness
Point readiness at a dependency-aware endpoint; failure removes the Pod from Service endpoints without a restart.
Step 4
Tune timing
Set initialDelaySeconds, periodSeconds, timeoutSeconds and thresholds to avoid flapping or premature restarts.
Step 5
Choose a handler
Pick httpGet, tcpSocket, exec, or grpc depending on what best reflects the container's true health.
What Interviewer Expects
- Correct action for each probe: restart, remove from traffic, or gate startup
- Awareness that startup probe suppresses the other two while running
- Knowledge of probe handlers (HTTP, TCP, exec, gRPC)
- Understanding of timing fields and their impact
- Why readiness prevents traffic to unready Pods
Common Mistakes
- Saying a failed readiness probe restarts the container
- Using the same endpoint and thresholds for liveness and readiness
- Omitting a startup probe for slow-booting apps, causing restart loops
- Setting initialDelaySeconds too low and killing healthy Pods
- Making the liveness endpoint depend on external services
Best Answer (HR Friendly)
“Kubernetes runs little health checks on each app. Liveness asks 'is it still alive?' and restarts it if not, readiness asks 'is it ready for users?' and holds back traffic until it is, and startup gives slow apps time to boot before the other checks begin. Together they keep apps self-healing.”
Code Example
apiVersion: v1
kind: Pod
metadata:
name: api
spec:
containers:
- name: api
image: myorg/api:1.0
ports:
- containerPort: 8080
startupProbe:
httpGet:
path: /healthz
port: 8080
failureThreshold: 30
periodSeconds: 10
livenessProbe:
httpGet:
path: /healthz
port: 8080
periodSeconds: 10
failureThreshold: 3
readinessProbe:
httpGet:
path: /ready
port: 8080
periodSeconds: 5
failureThreshold: 3Follow-up Questions
- What happens to traffic when a readiness probe fails?
- Why should a liveness endpoint avoid checking external dependencies?
- How does a startup probe prevent restart loops for slow apps?
- What probe handlers does Kubernetes support?
- How do initialDelaySeconds and failureThreshold interact?
MCQ Practice
1. What action does a failed liveness probe trigger?
A failed liveness probe causes the kubelet to restart the container to recover from an unhealthy state.
2. What does a failing readiness probe do?
A failing readiness probe removes the Pod from its Service's endpoints so no new traffic is routed to it, without restarting it.
3. What is the main purpose of a startup probe?
A startup probe holds off liveness and readiness checks so a slow-initializing container is not killed before it finishes booting.
Flash Cards
What does a liveness probe do on failure? — Restarts the container to recover from crashes or deadlocks.
What does a readiness probe do on failure? — Removes the Pod from Service endpoints so it receives no traffic — no restart.
When is a startup probe useful? — For slow-starting apps; it suppresses liveness and readiness until the app has booted, preventing premature restarts.
Which handlers do probes support? — httpGet, tcpSocket, exec command, and gRPC.
Continue Learning
Related Interview Questions
How can a badly configured liveness or readiness probe turn a healthy service into an outage?
hard
What are Kubernetes Liveness and Readiness Probes?
medium
What is Kubernetes and what problem does container orchestration solve?
easy
What is the difference between a ConfigMap and a Secret in Kubernetes?
easy