Day 54: Probes: liveness, readiness, startup
How Kubernetes knows if your app is actually healthy
Kubernetes can't know whether your app is working just because its process is running — a Node.js process can be alive but deadlocked, or up but not yet ready to serve traffic. Probes are how you tell it the difference.
- Liveness probe — "is this container still alive/functional?" Fails → kubelet restarts the container
- Readiness probe — "is this container ready to receive traffic right now?" Fails → removed from the Service's load-balancing pool, but NOT restarted
- Startup probe — for slow-starting apps: disables liveness/readiness checks until startup succeeds, avoiding a slow-booting app being killed prematurely by an impatient liveness probe
livenessProbe:
httpGet:
path: /healthz
port: 3000
initialDelaySeconds: 10
periodSeconds: 10
readinessProbe:
httpGet:
path: /ready
port: 3000
periodSeconds: 5A very common misconfiguration
Pointing liveness and readiness at the *same* endpoint is a common mistake: if a dependency (say, the database) is briefly down, a combined health check might report unhealthy and get the container restarted — when the correct behavior is just to mark it not-ready (stop sending traffic) and let it recover once the dependency returns, without a pointless restart.
Key terms
- Liveness probe
- Checks if a container is still functioning; failure triggers a restart.
- Readiness probe
- Checks if a container should receive traffic right now; failure removes it from load balancing without restarting.
Your app's database connection briefly drops for 5 seconds. Your liveness AND readiness probes both check "can I reach the database?" What happens, and why is it wrong?
