Cluster DNS

CoreDNS in the Cluster

Every cluster runs a DNS service — CoreDNS by default — as a Deployment with a ClusterIP, typically 10.96.0.10 under kubeadm. Pods receive resolver configuration through dnsPolicy:

• ClusterFirst (default) — cluster names resolve via CoreDNS; unknown names fall back to the host's upstream resolvers via the forward plugin.
• ClusterFirst with hostNetwork — requires explicit handling since the pod shares the node's network.
• None — ignore cluster DNS entirely and use dnsConfig nameservers you supply.

The magic is search domains: a pod gets ns.svc.cluster.local svc.cluster.local cluster.local appended, so mysql inside namespace shop resolves to mysql.shop.svc.cluster.local automatically.

Records and Configuration

Two record shapes matter:

• <service>.<ns>.svc.cluster.local → ClusterIP of a normal Service.
• <pod-ip-dashed>.<service>.<ns>.svc.cluster.local → individual pods of a headless Service (10-244-1-7.my-hl.ns.svc.cluster.local).

CoreDNS reads a ConfigMap, kube-system/coredns, reloaded automatically when it changes:

plugins:
- name: forward
  arguments: . 1.1.1.1
- name: cache
  parameters: 30

Each ready pod of a Service is registered; SRV records (_http._tcp.my-svc) expose ports for clients that need them.

Pitfalls and Interview Angles

Pitfall 1 — debugging app errors as DNS errors. Prove resolution first: kubectl run dnsutils --image=busybox:1.36 --rm -it -- nslookup mysql.shop. If that works, the failure is connectivity or credentials, not DNS.

Pitfall 2 — ndots and slow lookups. With ndots:5, a name like api.example.com triggers up to five search-domain probes before the real query, adding latency. Add a trailing dot (FQDN) or raise dnsConfig.options ndots for chatty clients.

Interview-ready: name CoreDNS and its ConfigMap, explain ClusterFirst search domains, and answer "pods cannot resolve services" with the check order: CoreDNS pods healthy → cluster domain matches → headless versus regular record shape → upstream forward for external names.