A civic API Pod’s readinessProbe fails while its livenessProbe still passes. What is the expected Service behavior?
Select an answer to reveal the explanation.
Short Explanation
Readiness is the ‘open for business’ sign; liveness is the ‘still alive’ check. When readiness fails but liveness passes, the Pod stays up but the Service takes it out of Endpoints so clients stop hitting it. Traffic waits until readiness succeeds again.
Full Explanation
If a civic API Pod’s readinessProbe fails while its livenessProbe still passes, the Service stops sending traffic to that Pod by removing it from Endpoints/EndpointSlices while the Pod keeps running. Readiness controls traffic admission; liveness controls restart. That separation lets municipal APIs shed load from a Pod that is temporarily unready without killing a process that is still alive.
Why the other options fail by concept: A failed readiness probe does not cause the kubelet to delete the Pod and recreate it on another node—that is closer to eviction/rescheduling narratives, not readiness. The Deployment does not scale to zero because one Pod fails readiness. kube-proxy does not rewrite the Pod IP into a temporary NodePort to keep sending traffic despite failed readiness.
Exam caveat: If all Pods fail readiness simultaneously (shared dependency), the Service can have zero backends—see the over-coupling anti-pattern. Liveness continuing to pass is expected and desirable during readiness-only faults. publishNotReadyAddresses on some Service types changes semantics—know defaults for ClusterIP app Services.
Operational check: Force readiness failure in a test Pod (bad path), kubectl get endpointslices for the Service, and confirm the Pod IP disappears while kubectl get pod still shows Running. Restore readiness and watch the address return without a container restart.