Health checks are control-plane primitives that allow an orchestrator to manage the lifecycle and traffic-readiness of a containerized process.

The Probe Triad

Kubernetes implements three distinct probe types to manage the failure domain.

Probe TypeQuestion AnsweredFailure ActionFailure Context
StartupIs the app still bootstrapping?Hold off other probes.Slow migrations, cache warm-up.
LivenessIs the process deadlocked?Restart Container.In-memory corruption, thread deadlock.
ReadinessCan the app handle traffic?Remove from Service.Dependency down, saturated IO.

Designing the Liveness Probe

The Liveness probe must be minimalist. Querying an external database in a liveness probe is an anti-pattern: if the DB is down, all replicas restart simultaneously, inducing a cluster-wide outage.

Failure Detection Math: Phi Accrual

Instead of binary "up/down" thresholds, advanced systems (Akka, Cassandra) use the \phiAccrual Failure Detector. It calculates the probability of failure based on the history of heartbeat inter-arrival times.

Mathematical Model: IfT_{last}is the time of the last heartbeat,\phiis defined as:

\phi(T_{now}) = -\log_{10}(P(T_{inter-arrival} > T_{now} - T_{last}))

Operational Risk: The Thundering Herd

A naive health check configuration can induce a "Thundering Herd" during recovery.

  1. Service A hits a resource limit and fails Liveness.
  2. Kubernetes restarts the container.
  3. The load balancer immediately floods the restarting container with traffic before it's ready.
  4. The container fails again, entering a CrashLoopBackOff.

Mitigation:

Sidecar Pattern for Probes

For complex health logic (e.g., checking multiple internal subsystems), move the logic to a Health Sidecar.

Implementation Checklist