The sanitation platform team asks which object supplies the stable ClusterIP that application Pods use as their nameserver for cluster DNS. What is the correct answer?
Select an answer to reveal the explanation.
Short Explanation
Apps don’t memorize every CoreDNS Pod’s personal cell number—they dial one stable front-desk line. That line is the cluster DNS Service (often still named kube-dns) whose selector points at CoreDNS Pods. The ClusterIP stays put while Pods churn behind it.
Full Explanation
The sanitation platform team should know that the stable ClusterIP application Pods use as their nameserver for cluster DNS comes from the kube-dns Service—or equivalently named cluster DNS Service—that selects the CoreDNS Pods. Applications do not memorize every CoreDNS Pod’s personal address; they dial one durable front-desk line whose selector points at the resolvers. That ClusterIP remains while Pods churn, and kubelet injects it into resolv.conf under normal cluster DNS policy.
Listing each CoreDNS Pod IP manually in every Deployment dnsConfig is fragile and not the platform contract. Relying on the kubelet config file’s static hostname alone with no Service involved does not provide cluster DNS. An Ingress controller ClusterIP that terminates DNS over HTTPS is not the in-cluster nameserver model for Service discovery.
Exam caveat: the Service name may still be kube-dns even when implementation Pods are CoreDNS—recognize both on exams. Changing that ClusterIP is highly disruptive because existing Pods already embedded the old nameserver at creation time.
Operational check: kubectl -n kube-system get svc kube-dns -o wide, compare ClusterIP to nameserver lines in a Pod’s /etc/resolv.conf, and confirm Endpoints list Ready CoreDNS Pods answering queries. Alert if kube-dns Endpoints drop to zero even when some CoreDNS Pods appear Running.