By default, when a Pod fails its readiness probe, how does that affect Service traffic?
Select an answer to reveal the explanation.
Short Explanation
Readiness is the “open for business” light. Fail it, and the Service stops sending customers to that Pod—Endpoints drop the IP—while the Pod may still be alive. It’s traffic control, not an instant kill switch from kube-proxy.
Full Explanation
By default, when a Pod fails its readiness probe, the Pod’s IP is removed from the Service Endpoints so new traffic is not sent to it. Readiness gates Service membership: NotReady means off the Endpoints roster for normal Service traffic. That protects citizens from being load-balanced to a municipal Pod that is running but not prepared to serve requests.
The Pod is not deleted immediately with a replacement created by kube-proxy when readiness fails—that confuses readiness with crash restart and replica replacement behavior. The Pod does not keep receiving Service traffic while kubelet freezes its containers on readiness failure. The Service ClusterIP is not reallocated until the Pod becomes Ready again; the ClusterIP remains stable while Endpoints membership changes.
Exam caveat: liveness probe failures restart containers; readiness probe failures remove Pods from Endpoints—do not swap those semantics on exam questions. publishNotReadyAddresses: true is an intentional override when you truly need NotReady addresses published. Operational check: force a readiness failure on one Pod behind a Service; kubectl get endpoints and observe removal; restore readiness and observe re-addition; confirm curls stop hitting the NotReady Pod. Use this demo in city platform training to explain safer rolling updates.