Building-permits workloads suddenly cannot resolve Kubernetes Service DNS names cluster-wide, and CoreDNS pods are down. How should this be classified?
Select an answer to reveal the explanation.
Short Explanation
When CoreDNS is down, it's like the city directory vanished—pods still run, but they cannot look up svc.cluster.local names. Treat it as a core component outage, not a storage quirk.
Full Explanation
CoreDNS (or the cluster DNS service) is how pods resolve svc.cluster.local and related names across a municipal cluster. When CoreDNS pods are down cluster-wide, building-permits and other workloads suddenly cannot resolve Service DNS names even though application pods may still run and nodes may remain Ready. Classify this correctly as a critical cluster-component outage affecting name resolution used by pods across the cluster—not a minor cache miss, not a storage quirk, and not merely a node condition flip. DNS failure should not be classified only as a node NotReady issue; nodes can stay Ready while in-cluster DNS is broken, so framing the outage solely as NotReady mis-prioritizes the response. It is not a harmless cache miss: without working cluster DNS, many apps cannot find dependencies and city services degrade quickly as lookups fail. StorageClass provisioning errors do not uniquely disable CoreDNS resolution; conflating CSI provisioning with DNS points troubleshooting at the wrong stack when CoreDNS pods themselves are down. Exam caveat: NodeLocal DNSCache can mask or complicate symptoms on some nodes; still, if CoreDNS itself is down, treat cluster DNS as a P1 control-plane-adjacent outage. Always distinguish “cannot resolve names” from “names resolve but TCP to the ClusterIP fails.” Operational check: Restore the CoreDNS Deployment and pods, verify the kube-dns/CoreDNS Service has ready Endpoints, test nslookup or dig from a debug pod to a known Service FQDN in the permits namespace, and confirm applications recover Service name lookups before closing the incident.