Kubernetes Health Probe Definition

Kubernetes Health Probes are essential mechanisms that check the health of containers, ensuring reliability and availability in cluster environments.

Kubernetes Health Probe Definition is the precise characterization of a probe as a periodic, kubelet-executed diagnostic check against a specific container, formally producing one of three outcomes, Success, Failure, or Unknown, and used as the sole formal input by which the platform determines whether a container should be restarted or whether a Pod should be included in Service traffic routing. A probe is defined entirely at the container level, and its result is scoped strictly to that single container, never inferred from or shared with any other container in the same Pod.

Formal Probe Types

Liveness Probe

A liveness probe formally answers whether a container's process should continue running as-is; repeated Failure results, up to a configured failureThreshold, cause the kubelet to kill and restart the container according to the Pod's restartPolicy.

Readiness Probe

A readiness probe formally answers whether a container is currently able to serve requests; its result determines only inclusion in the Pod's Ready condition and, transitively, in the set of ready addresses recorded for any Service selecting that Pod, and formally never triggers a container restart on its own.

Startup Probe

A startup probe formally answers whether a container's initial startup sequence has completed; while a startup probe is configured and has not yet succeeded, the kubelet formally suspends evaluation of the liveness and readiness probes for that same container.

liveness probe result \to restart decision, readiness probe result \to traffic inclusion decision

Formal Probe Mechanisms

httpGet

An httpGet probe formally issues an HTTP GET request to a specified path and port on the container; the probe is considered Success if the response status code falls within the 200–399 range, and Failure otherwise.

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080

tcpSocket

A tcpSocket probe formally attempts to open a TCP connection to a specified port; the probe is Success if the connection is established, and Failure if it cannot be, without exchanging any application-level data.

readinessProbe:
  tcpSocket:
    port: 5432

exec

An exec probe formally runs a specified command inside the container's namespace; the probe is Success if the command exits with status code zero, and Failure for any non-zero exit code.

livenessProbe:
  exec:
    command: ["cat", "/tmp/healthy"]

grpc

A grpc probe formally invokes the standard gRPC health checking protocol against a specified port; the probe's result is determined by the health service's own reported status rather than an HTTP status code or process exit code.

readinessProbe:
  grpc:
    port: 9090

Formal Timing Parameters

The Defined Fields

Every probe formally accepts a fixed set of timing parameters: initialDelaySeconds, the delay before the first probe execution; periodSeconds, the interval between probe executions; timeoutSeconds, the duration after which an in-flight probe is considered failed; successThreshold, the number of consecutive successes required to transition from failing to passing; and failureThreshold, the number of consecutive failures required to transition from passing to failing.

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 15
  periodSeconds: 10
  timeoutSeconds: 2
  failureThreshold: 3
  successThreshold: 1

state transitions require \geq threshold consecutive results, not a single result

Formal Independence Between Probe Types

No Shared State

Each of the three probe types, where all are configured on the same container, formally maintains its own independent state machine, its own consecutive success and failure counts, and its own timing schedule; a failing readiness probe formally has no bearing on the liveness probe's own passing or failing state, and vice versa.

Per-Container Scope

Because probes are formally defined per container, a Pod with multiple containers formally evaluates each container's probes independently; one container's containers being unready does not, by definition, affect another container's probe results within the same Pod, though it may still affect the Pod's aggregate Ready condition depending on how that condition is computed across all containers.

kubectl describe pod codartium-app-abc123
kubectl get events --field-selector reason=Unhealthy -n codartium-team

Why Probes Are Formally Separated by Purpose

Defining liveness, readiness, and startup as three formally distinct probe types, each feeding a different downstream decision, restart, traffic inclusion, or probe suspension, is what allows a container's process health, its request-serving readiness, and its startup completion to be expressed and evaluated independently, since these three conditions are not, in general, equivalent for any given application.