A building-permit API Pod has started its process but is still loading reference data and cannot answer HTTP yet. How should orchestration’s service layer treat that replica?
Select an answer to reveal the explanation.
Short Explanation
A process can be alive and still useless to callers—like a ticket window with the lights on but the clerk still unpacking. Orchestration keeps not-ready replicas off the service endpoints. Ready means fit to serve, not merely started.
Full Explanation
A building-permit API Pod can have a running main process while still loading reference data and not yet able to answer HTTP. Orchestration’s service layer must omit that replica from Service endpoints until it passes readiness; process existence is not the same as ready to serve. Ready endpoints are what callers actually hit; including not-ready Pods causes timeouts and 5xx errors during boot or cache warm-up. Sending production traffic solely because a PID exists treats “started” as “serving,” which fails warm-up-heavy municipal APIs. Marking Ready only because the worker node passed cloud-init confuses node bootstrap health with application readiness on that node. Deleting the Service until every historical Pod has finished booting once removes discovery for already-healthy replicas and turns a normal rollout into an avoidable outage. Exam caveat: readiness probes must match the true serve path (HTTP check on the correct port and path); a probe that succeeds too early still puts half-loaded Pods into endpoints and defeats the purpose. Operational check: watch endpoints during startup—Pods exist but are absent from endpoints until Ready—then confirm only Ready Pods receive Service traffic with kubectl get endpoints or EndpointSlices.