Free tools Windows power users keep installed
One-click scans. No signup required.
Use a readiness probe to stop a Pod that cannot serve requests from being treated as a ready backend. Kubernetes also marks a Pod unready when its Node’s Ready condition is not true. That updates Kubernetes Service backends, but it does not guarantee that every external load balancer removes the node from its target pool: that behavior depends on the cloud provider or load-balancer integration.
How Kubernetes decides whether a Pod receives Service traffic
A readiness probe reports whether a container can accept requests. When it fails, Kubernetes marks the Pod unready and removes its address from the EndpointSlices used by matching Services. The container keeps running, and readiness checks continue; a later successful check can make it eligible again. See the Kubernetes probe documentation.
As an Amazon Associate I earn from qualifying purchases.
Readiness is about eligibility for Service traffic, not whether the process exists. For a serving container whose ability to handle requests can change after startup, configure a check that reflects whether it can serve the relevant request path. Kubernetes supports HTTP, TCP, gRPC, and exec probes. Keep the check lightweight and representative of the service’s ability to respond.
Kubernetes also ties Pod readiness to node health: a Pod’s Ready condition is false when its Node Ready condition is not true. Such a Pod is therefore not a ready Service backend. This is distinct from external load-balancer target health, which is handled separately.
#1 Best Overall
Choose readiness, liveness, and startup probes for different jobs
| Probe | What failure does | Use it for | Important caution |
|---|---|---|---|
| Readiness | Makes the Pod ineligible for Service traffic; the container continues running and checks continue. | Conditions that mean the application should temporarily stop receiving requests. | Do not use a check that reports success merely because the process is alive if it cannot serve requests. |
| Liveness | Can cause the container to be restarted. | A failure from which restarting the container is the intended recovery action. | Do not make temporary overload or dependency trouble a restart trigger unless restart is appropriate; aggressive checks can worsen load-related failures. |
| Startup | Defers readiness and liveness checks until startup succeeds. | Applications that need time to initialize. | Use it to avoid premature probe failures during slow startup. |
Startup probes protect initialization; after one succeeds, Kubernetes begins liveness and readiness probing. Readiness and liveness should not be interchangeable: one changes traffic eligibility, while the other can restart a container. Kubernetes explains the probe types and their effects in its official probe guide.
Understand what externalTrafficPolicy changes
For a LoadBalancer Service, externalTrafficPolicy determines how traffic arriving at a node is handled. Cluster is the default and can route to endpoints across the cluster. Local forwards only to endpoints on the receiving node; it preserves client source IP and avoids a second hop, but traffic sent to a node without a local endpoint is dropped. The tradeoffs and API behavior are described in the Service API reference.
| Policy | Endpoint routing | Client source IP and hops | If the node has no local endpoint |
|---|---|---|---|
Cluster |
Can route to endpoints elsewhere in the cluster. | May require cross-node forwarding; source-IP behavior differs from Local. | A local endpoint is not required for cluster-wide endpoint routing. |
Local |
Uses endpoints on the receiving node only. | Preserves client source IP and avoids a second hop. | Traffic reaching that node is dropped. |
With externalTrafficPolicy: Local, Kubernetes exposes healthCheckNodePort so an external system can check whether a node has local endpoints for the Service. The field’s purpose does not mean every provider configures its load balancer identically. Kubernetes explicitly leaves managed load-balancer health-check implementation to providers and integration code; consult the documentation for your actual provider or load-balancer integration. See Kubernetes’ Service documentation and Service API reference.
Diagnose a Pod or node that still appears to receive traffic
- Check the Pod Ready condition. Inspect the Pod’s status and probe events. A running container is not proof that the Pod is ready to serve.
- Inspect the Service’s EndpointSlices. Check the endpoint’s
ready,serving, andterminatingconditions rather than inferring routing from process state alone. Normally,readyis a shortcut forservingand notterminating;publishNotReadyAddressesis an exception. The EndpointSlice conditions are described in the EndpointSlice documentation. - Check whether traffic enters through an external LoadBalancer Service. A readiness failure updates Pod readiness and Service backends; it does not, by itself, establish that an external system has removed a node from its target pool.
- If the Service uses
externalTrafficPolicy: Local, inspecthealthCheckNodePort. Verify that the external load balancer checks it and removes nodes without local endpoints according to the provider’s documented behavior. - Review probe intent and timing. Make readiness represent ability to serve; reserve liveness for failures where restarting is intended, and use startup probes when initialization is slow.
What readiness can and cannot guarantee
A readiness probe is the Kubernetes-native control for removing an unhealthy Pod from ready Service backends. Node readiness also affects Pods’ Ready conditions. Neither fact alone defines how an external load balancer health-checks nodes: for that, confirm the provider or integration behavior, particularly when using externalTrafficPolicy: Local.
Quick Recap
Best Value
Rank #3
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
