Liveness restarts, readiness gates traffic, startup protects slow boots.

Three probes answer three different questions. Mixing them up is one of the most common causes of self-inflicted outages.

Liveness

Is it broken beyond repair?

Fails: the kubelet kills and restarts the container. Use for deadlocks, never for "busy".

Readiness

Can it take traffic now?

Fails: the Pod is removed from Service endpoints. The container keeps running and can recover.

Startup

Has it finished booting?

Holds liveness and readiness back until it passes, so a slow JVM is not killed during start.

probes

startupProbe:
  httpGet: {path: /healthz, port: 8080}
  failureThreshold: 30  periodSeconds: 10
livenessProbe:
  httpGet: {path: /healthz, port: 8080}
  failureThreshold: 3
readinessProbe:
  httpGet: {path: /ready, port: 8080}
  periodSeconds: 5

Probes tell Kubernetes when to restart and when to send traffic

The kubelet runs probes against each container and reacts to the results. A liveness probe asks whether the process is fundamentally broken, for example deadlocked. If it fails past its threshold the kubelet kills and restarts the container. A readiness probe asks whether the container can serve traffic right now. If it fails, the Pod's IP is removed from the endpoints of every Service that selects it; the container is not touched. A startup probe holds the other two back until the application has finished starting, which protects slow-booting services from being restarted before they are up.

The classic interview trap is a container that is merely overloaded. If its liveness probe times out under load, the kubelet restarts it, throwing away progress and adding restart cost to an already struggling system. The right design is for readiness to fail temporarily so traffic drains away while the container catches up, and for liveness to check only for real failure such as a stuck event loop.

Readiness also protects rollouts. A Deployment's rolling update waits for new Pods to become Ready before it terminates old ones. Without a meaningful readiness probe Kubernetes cannot tell a working Pod from a broken one and may replace healthy Pods with broken ones.

Reveal the three probes, then the timeline. Gotcha: do not make the liveness probe depend on a downstream database. A database outage would then restart every replica at once and turn a partial failure into a total one.