A library catalog frontend must call the search backend on OKE, but search Pod IPs change whenever replicas restart. What orchestration concern gives callers a stable name that tracks currently healthy replicas?
Select an answer to reveal the explanation.
Short Explanation
Replica IPs are revolving doors; a service name is the lobby directory. Callers use that stable name while the orchestrator keeps the healthy-member list current. Hard-coded Pod IPs go stale the moment a replica moves.
Full Explanation
Library catalog frontends must call search backends whose Pod IPs change whenever replicas restart, reschedule, or roll. Service discovery solves that by giving callers a stable service name (and ClusterIP/DNS) while the control plane maintains the set of currently healthy endpoints behind that name. Callers keep the same address; membership updates as Pods become Ready or disappear. Baking Pod IPs into the frontend image freezes ephemeral addresses into an immutable artifact, so the next restart breaks every baked client until a rebuild. Spreadsheet updates by clerks after each deploy are a human race against churn and cannot keep pace with orchestration events. Publishing only as NodePort and hard-coding every worker address couples clients to node topology and ports, which change with cluster membership and are not the in-cluster discovery model. Exam caveat: a stable Service name is only useful when selectors match Pod labels and readiness gates keep not-ready Pods off endpoints—otherwise DNS exists but backends are empty or unhealthy. Operational check: resolve the service DNS from a frontend Pod, confirm endpoints list matches Ready search Pods, restart a search replica, and verify the name still works while the old IP disappears from endpoints.