Library applications across many namespaces suddenly cannot resolve Service names even though the Service objects still exist. CoreDNS replicas recently crashed. What is the impact?
Select an answer to reveal the explanation.
Short Explanation
The suite doors still exist, but the directory desk is empty. If CoreDNS is down, name lookups fail even though Services and Endpoints are fine—clients that need DNS feel it immediately.
Full Explanation
If CoreDNS replicas crash across many library namespaces, the impact is a cluster DNS outage that breaks Service discovery by name even though Service and Endpoints objects still exist in the API. The suite doors remain on the floor plan, but the directory desk is empty—clients that look up *.svc.cluster.local fail immediately. Hard-coded ClusterIP traffic might still work, yet normal DNS-based discovery does not until CoreDNS is restored.
etcd does not serve DNS when CoreDNS is down. ClusterIP DNS does not keep working without CoreDNS while only LoadBalancer Services fail—both rely on name resolution for DNS-based clients. kube-proxy does not recreate every Service as a NodePort to make DNS unnecessary during the outage.
Exam caveat: distinguish DNS timeouts and NXDOMAIN from later connect errors against a resolved IP. Municipal production clusters run multiple CoreDNS replicas and protect them with appropriate PodDisruptionBudgets to reduce this blast radius.
Operational check: restore CoreDNS Deployment health, confirm the kube-dns Service has Ready Endpoints, dig a known Service from a library Pod, and watch application errors related to name resolution clear. Municipal operators should treat this as a platform reliability concern, not an application bug in every namespace.