CoreDNS resolves hostnames to IP addresses inside a Kubernetes cluster. Pods can use names to reach Services instead of tracking changing IP addresses or maintaining individual /etc/hosts files. CoreDNS is the default cluster DNS server in the Kubernetes setup described here. section 1.4.3 section 6.2 section 6.1
For a DNS administration task, check the server, its Service, and the pod’s resolver configuration:
- Find the CoreDNS Deployment and its pods in kube-system with kubectl -n kube-system get deploy and kubectl -n kube-system get po. Scale the Deployment when analysis identifies CoreDNS as a DNS-query bottleneck; verify that the requested replicas appear. section 6.2.3
- Find the kube-dns Service in kube-system. Despite its name, this Service fronts CoreDNS; its ClusterIP is the DNS address configured for pods. section 6.1 section 6.2.2
- Inspect a pod’s /etc/resolv.conf for its nameserver and search domains. Check the kubelet’s clusterDNS setting in /var/lib/kubelet/config.yaml and its kubelet-config ConfigMap when changing the DNS Service IP; CoreDNS has a separate ConfigMap. section 6.1 section 6.2.2
root@kind-control-plane:/# kubectl exec -it netshoot -- bash bash-5.1# cat /etc/resolv.conf search default.svc.cluster.local svc.cluster.local cluster.local nameserver 100.96.0.10 options ndots:5
A pod’s resolver file shows the DNS Service IP as nameserver 100.96.0.10 and the search domains used to expand short names. section 6.1
Changing the cluster DNS address
In a fresh kind-cluster exercise, new Services move to Service CIDR 100.96.0.0/16 and the recreated kube-dns Service receives 100.96.0.10. Update the kubelet DNS configuration, apply it to the node, then create a new pod. Confirm that /etc/resolv.conf names 100.96.0.10 and that nslookup resolves a domain. The node, pod, and Service CIDRs must remain distinct. section 6.1
Distinguishing DNS failure from Service failure
Scale the CoreDNS Deployment to zero in a practice cluster: a pod’s wget request to a Service name returns “bad address.” Restore CoreDNS and the name resolves to the Service IP, allowing the request to succeed. For a Service in another namespace, try <service-name>.<namespace-name> or its full name, <service-name>.<namespace-name>.svc.cluster.local, rather than assuming the short name will resolve. section 6.2.3 section 6.2.4
For CKA practice, be ready to locate CoreDNS, change and verify cluster DNS configuration, scale its replicas, and test resolution from inside a pod. A lookup failure can also be a naming-scope mistake: inspect /etc/resolv.conf before changing the DNS server. section 6.1 section 6.8 section 6.2.4
