Health Checks: Liveness-, Readiness- und Startup-Probes

Kubernetes cannot know your app is healthy just because the process is running. Probes let you tell the kubelet how to check real application health.

There are three: liveness (restart if broken), readiness (gate traffic), and startup (protect slow boots).

If the liveness probe fails, the kubelet restarts the container. Use it to recover from deadlocks the process cannot detect itself.

If readiness fails, the Pod is removed from Service endpoints but NOT restarted. This stops traffic to a Pod that is temporarily unable to serve.

Liveness answers should I restart this; readiness answers should I send traffic. Using readiness as liveness causes needless restarts; the opposite causes failed requests.

A startup probe disables liveness and readiness until the app finishes booting, perfect for slow-starting legacy apps.

Probes can use httpGet, a raw tcpSocket connection, or run a command with exec, succeeding when the command exits 0.

Key knobs: initialDelaySeconds, periodSeconds, timeoutSeconds, failureThreshold, and successThreshold let you balance speed of detection against false positives.

Readiness probes make rolling updates safe: new Pods only receive traffic once ready, so a broken release does not serve users.

Probe failures show up in events. Describe the Pod to see why it restarts or never becomes ready.

Avoid heavy health endpoints that themselves cause timeouts, and avoid too-short initialDelaySeconds that restart Pods before they finish booting.

Test what you have learned.

You learned the three probe types: liveness restarts, readiness gates traffic, startup protects slow boots, the http/tcp/exec mechanisms, timing knobs, and how readiness keeps rollouts safe.