✦ For everyone, free.

Practical knowledge for real and everyday life

Home

Kubernetes Endpoint Readiness Management

Kubernetes Endpoint Readiness Management ensures services communicate only with healthy endpoints through liveness and readiness probes.

Kubernetes Endpoint Readiness Management refers to the deliberate configuration and operational discipline of ensuring that a pod is only marked as a valid Service endpoint once it can genuinely handle traffic, and is promptly removed from that pool the moment it can no longer do so, using readiness probes as the primary control surface for this gating behavior.


Readiness as the Gate Between Pod and Endpoint

Distinct From Liveness

Readiness is deliberately separate from liveness: a liveness probe failure causes a container restart, while a readiness probe failure only removes the pod from Service endpoints without restarting it, since a pod may be temporarily unable to serve traffic — warming a cache, waiting on a downstream dependency — without being unhealthy enough to warrant a restart. Readiness management treats these as distinct failure semantics requiring distinct probe configuration.

readinessProbe:
  httpGet:
    path: /readyz
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5
  failureThreshold: 3
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 15
  periodSeconds: 10

Effect on EndpointSlice Membership

A pod passing its readiness probe is marked ready: true in the corresponding EndpointSlice entry and becomes eligible to receive traffic through the Service; a pod failing its readiness probe has this flag flipped to false, causing kube-proxy to stop routing new connections to it, without the pod being removed from the cluster or restarted.

kubectl get endpointslice ledger-api-x7k2p -o jsonpath='{.endpoints[*].conditions.ready}'

Designing Readiness Probes

Reflecting True Serving Capability

A well-managed readiness probe checks conditions that genuinely reflect the ability to serve traffic correctly — an established database connection pool, a warmed cache, successful completion of startup dependencies — rather than merely confirming the process is running, since a process that is alive but not yet functional would otherwise be incorrectly marked ready.

readinessProbe:
  httpGet:
    path: /readyz
    port: 8080
@GetMapping("/readyz")
public ResponseEntity<String> readiness() {
    if (!cacheWarmed || !dbPool.isHealthy()) {
        return ResponseEntity.status(503).body("not ready");
    }
    return ResponseEntity.ok("ready");
}

Avoiding Overly Aggressive Failure Thresholds

Readiness management balances responsiveness against stability: a failureThreshold set too low causes pods to flap in and out of the endpoint pool on transient blips, while one set too high delays removal of a genuinely unhealthy pod, prolonging the window during which traffic is routed to a backend that cannot serve it correctly.


Readiness During Startup

Preventing Premature Traffic

Newly created pods are excluded from Service endpoints by default until their readiness probe first succeeds, which is the mechanism that prevents traffic from being routed to a pod still initializing. Setting initialDelaySeconds appropriately avoids the probe firing before the application has had any chance to start listening at all.

Startup Probes for Slow-Initializing Workloads

For workloads with unusually long initialization windows, a separate startupProbe can be configured to suppress both liveness and readiness checking until startup completes, preventing a slow-starting pod from being prematurely killed by liveness checks or marked unready indefinitely by a readiness probe misconfigured for steady-state behavior.

startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  failureThreshold: 30
  periodSeconds: 10

Readiness During Shutdown

Graceful Endpoint Removal Before Termination

When a pod is deleted, Kubernetes marks it terminating in the EndpointSlice and begins removing it from Service routing concurrently with sending the termination signal to the container, rather than waiting for the container to fully exit first. Readiness management includes ensuring the application's shutdown sequence tolerates a brief window of in-flight requests arriving after termination has begun, since propagation of the endpoint removal across every node is not instantaneous.

lifecycle:
  preStop:
    exec:
      command: ["sh", "-c", "sleep 5"]
terminationGracePeriodSeconds: 30

Coordinating preStop Delay With Endpoint Propagation

A short preStop sleep is a common readiness management pattern specifically to bridge the gap between the control plane deciding to remove an endpoint and every node's kube-proxy having actually applied that change, reducing the number of requests that would otherwise be sent to a pod that is already shutting down.


Operational Monitoring of Readiness Behavior

Tracking Readiness Flap Rate

Endpoint readiness management includes monitoring how frequently pods transition between ready and not-ready states in steady-state operation; a high flap rate on an otherwise stable workload typically indicates an overly strict or poorly targeted readiness check rather than a genuine intermittent capacity problem.

kubectl get events --field-selector reason=Unhealthy --sort-by=.lastTimestamp
Starting Ready Terminating Only the "Ready" state receives new Service traffic.