An HR LoadBalancer Service remains External IP Pending in a bare-metal lab with no cloud load-balancer controller. What explains the stuck state?
Select an answer to reveal the explanation.
Short Explanation
LoadBalancer is a request for a real front-door IP from a provider—no cloud or MetalLB-style controller, no address, forever Pending. Lab clusters need a provider or a different Service type.
Full Explanation
LoadBalancer Services require a cloud or metal load-balancer provider/controller to allocate an external address. In a bare-metal HR lab with no such controller, the Service remains External IP Pending because nothing fulfills the allocation request—no cloud or MetalLB-style controller, no address. The Pod's restartPolicy OnFailure does not block LoadBalancer allocation; restartPolicy governs container restarts. CoreDNS does not need to list the Service name under NodePort before an IP appears; DNS is unrelated to cloud LB allocation. Pending does not clear automatically once three Ingress objects reference the Service; Ingress references do not substitute for an LB provider. Exam caveat: Use NodePort/ClusterIP in labs without a provider, or install MetalLB/equivalent. Know Pending external IP as the classic missing-provider signal. Operational check: Confirm no LB controller exists, either install one for the lab or change Service type, and verify clients can reach HR via the chosen exposure method. In municipal production practice, record the finding in the incident ticket with command output snippets, confirm the fix under change control, and re-validate the user-facing civic service before closing the change window.