---

Previous Parts in This Series

If you are joining this series here, you may want to read the earlier parts first:

• Part 0 – Before You Begin – What You Need to Build a Kubernetes Cluster with kubeadm

• Part 1 – Preparing Linux Nodes for Kubernetes

• Part 2 – Installing and Configuring containerd for Kubernetes

• Part 3 – Installing Kubernetes with kubeadm and Bootstrapping the Cluster

This guide is structured sequentially, and each part builds on the previous one.

---

Why DNS is critical in Kubernetes?

Once a Kubernetes cluster is bootstrapped and nodes are in the Ready state, one of the first components that directly impacts application stability is cluster DNS.

In Kubernetes, almost all service-to-service communication depends on DNS-based discovery. Applications rarely connect using pod IP addresses directly. Instead, they use service names that Kubernetes resolves internally.

If DNS is unstable:

• Pods fail to connect to services

• Applications experience random timeouts

• Health checks start failing

• Debugging becomes difficult

This makes understanding CoreDNS behavior essential before moving forward with storage or platform services.

---

How service discovery works in Kubernetes?

Kubernetes provides built-in DNS-based service discovery.

When a service is created, Kubernetes automatically assigns a DNS record using a structured naming convention.

Example service:

my-service.namespace.svc.cluster.local

Inside any pod in the cluster, this name can be resolved to the ClusterIP of the service.

The flow is:

1. Pod sends DNS query

2. Query reaches CoreDNS service

3. CoreDNS checks cluster records

4. CoreDNS returns service IP

This process is internal and does not require external DNS.

---

Role of CoreDNS in the cluster

CoreDNS acts as:

• Cluster service discovery engine

• DNS server for pods

• Recursive resolver for external domains

This means CoreDNS can resolve:

• Kubernetes services

• External internet domains

• Internal enterprise domains

depending on configuration.

To observe CoreDNS pods:

kubectl get pods -n kube-system

You should see CoreDNS pods in Running state.

---

Observing DNS behavior from inside a pod

You can validate DNS resolution by running a temporary test pod:

kubectl run dns-test --image=busybox:1.35 --rm -it -- nslookup kubernetes.default

Expected result:

• DNS resolution succeeds

• Cluster service IP is returned

This confirms cluster-internal DNS is working.

---

Common DNS failure patterns in new clusters

Some typical symptoms include:

• CoreDNS pods restarting repeatedly

• Pods unable to resolve service names

• Applications failing to connect internally

• Slow or timing-out DNS queries

These issues are often caused by:

• Incorrect upstream DNS configuration

• Network plugin timing issues

• Misconfigured CoreDNS forwarding behavior

---

Understanding the CoreDNS forward plugin

By default, CoreDNS includes a configuration block similar to:

forward . /etc/resolv.conf

This tells CoreDNS:

“If a query is not for a Kubernetes service domain, forward it to the upstream DNS servers configured on the node.”

In typical environments:

• Nodes have valid DNS resolvers

• External queries resolve successfully

• CoreDNS remains stable

However, in restricted or fully air-gapped clusters, this behavior can cause problems.

---

Fixing CoreDNS in restricted or air-gapped environments

In clusters where:

• Nodes do not have reachable upstream DNS

• /etc/resolv.conf contains invalid or unreachable servers

• External DNS resolution is not required

CoreDNS may experience repeated timeouts while forwarding queries. This can lead to:

• Readiness probe failures

• Pod restarts

• DNS latency issues

In such cases, the forwarding behavior can be disabled.

Edit the CoreDNS configuration:

kubectl edit configmap coredns -n kube-system

Locate the forward block and comment it out or remove it.

This restricts CoreDNS to cluster-internal resolution only, which is sufficient for fully isolated environments.

---

Validating DNS after configuration changes

After modifying CoreDNS:

Restart or wait for pods to reload configuration, then test again:

kubectl get pods -n kube-system

Then run:

kubectl run dns-test --image=busybox:1.35 --rm -it -- nslookup kubernetes.default

If resolution works consistently and CoreDNS pods remain stable, the cluster DNS layer is now reliable.

---

Stability checklist before proceeding further

Before installing storage or platform services, verify:

• ✅ CoreDNS pods are stable

• ✅ Nodes remain in Ready state

• ✅ Service names resolve from pods

• ✅ No repeated DNS timeouts are observed

A stable DNS layer ensures predictable behavior for all higher-level components.

---

What’s next

In Part 5, we will move to the storage layer and deploy a distributed persistent storage solution inside the cluster to support stateful workloads.