Workloads with no readiness probe

Started is not the same as ready

The moment a container process starts, the pod is added to its Service’s EndpointSlice and begins receiving traffic. That happens whether or not the application has loaded configuration, warmed a cache, established a connection pool or bound its listener.

For an application that starts in milliseconds the gap does not matter. For a JVM service, a framework with heavy initialisation, or anything that pre-loads data, the gap is seconds, and every request arriving in it fails.

Rollouts are where this actually bites

During a rolling update Kubernetes replaces pods in batches. With no readiness probe it considers each new pod available immediately and proceeds to terminate the next old one.

The result is a rollout that reports success while dropping a slice of traffic at every step. It is intermittent, brief, and looks like a network blip rather than a deploy problem. That is why it survives so many deployments before anyone traces it.

What a good readiness check tests

Unlike liveness, readiness should consider dependencies. A pod that cannot reach its database genuinely should not receive traffic, and removing it from the endpoint pool is exactly right.

The failure is recoverable: the pod stays alive, keeps being probed, and rejoins when the check passes. Nothing restarts.

Readiness also gates disruption

kubectl drain and the eviction API respect readiness through PodDisruptionBudgets. A workload with no readiness probe reports every pod as ready the instant it starts, so a budget requiring “at least 2 available” can be satisfied by two pods that cannot serve, and the drain proceeds into an outage.

Selecting containers where readinessProbe is null

kubectl get deploy,statefulset,daemonset -A -o json | jq -r '
  .items[] | . as $w | .spec.template.spec.containers[]
  | select(.readinessProbe == null)
  | "\($w.kind) \($w.metadata.namespace)/\($w.metadata.name): \(.name)"'

Where it matters least

A DaemonSet with no Service in front of it, or a worker consuming from a queue rather than serving requests, has no endpoint pool to be added to. The probe adds little there, and this finding can reasonably be dismissed for those workloads.