Probes & Self-Healing

Probes & Self-Healing

Step 1 of 12

startupchecking

The container is booting. Only the startup probe runs; liveness and readiness wait for it.

The Idea

The kubelet probes each container. A liveness probe that keeps failing makes it restart the container. A readiness probe that fails takes the Pod out of its Services' endpoints, with no restart. A startup probe holds the other two back until a slow-starting app is up.

Real-World Example

A service needs a minute to boot and warm its caches. A startup probe grants that minute, readiness keeps traffic off until the caches load, and liveness later catches a deadlock and restarts it. If it keeps crashing, restarts back off exponentially: CrashLoopBackOff.

The Tradeoff

Liveness probes need care. Misconfigured, they restart containers under heavy load, which pushes more load onto the rest — a cascading failure. Probe the process itself, and let readiness say "not right now".

Hands-On

# illustrative — three probes on one container (30 × 2 s = up to 60 s to start)
startupProbe:
  httpGet: { path: /healthz, port: 8000 }
  failureThreshold: 30
  periodSeconds: 2
readinessProbe:
  httpGet: { path: /ready, port: 8000 }
  periodSeconds: 5
livenessProbe:
  httpGet: { path: /healthz, port: 8000 }
  periodSeconds: 10

Your turn

Put the steps in the right order.

1. 1Readiness passes: the Pod joins the Service's endpoints↑↓
2. 2The container starts; only the startup probe runs↑↓
3. 3Later, liveness fails repeatedly and the kubelet restarts the container↑↓
4. 4The startup probe succeeds; liveness and readiness begin↑↓

Check order

Mini quiz

1 / 3

A readiness probe fails. The kubelet:

• ARestarts the container
• BLeaves it running, and the Pod is taken out of Service endpoints
• CDeletes the Pod
• DMoves the Pod to another node

Sources

• Liveness, readiness and startup probes — Kubernetes Documentation
• Configure liveness, readiness and startup probes — Kubernetes Documentation
• Pod lifecycle — Kubernetes Documentation