A public-health cluster sees DNS latency during a surge. CoreDNS runs as a Deployment behind the cluster DNS Service. Which admin action correctly scales name resolution capacity?
Select an answer to reveal the explanation.
Short Explanation
Picture CoreDNS like extra clerks at a busy information desk—when the line gets long, you add clerks, not tear down the desk’s phone number. Scaling the CoreDNS Deployment adds resolvers while the kube-dns Service keeps handing traffic to whichever pods match its selector. Killing the Service or hoping hostNetwork saves you just breaks cluster DNS for everyone else.
Full Explanation
In typical clusters CoreDNS is deployed as a Deployment in kube-system and fronted by a Service commonly named kube-dns. Scaling that Deployment increases concurrent DNS query capacity without changing how Pods discover the cluster DNS ClusterIP via kubelet DNS configuration. Administrators should verify the Service endpoints after scaling. Removing the DNS Service, scaling etcd for this purpose, or forcing hostNetwork on apps are not correct ways to add CoreDNS capacity.