Introduction

If a CoreDNS pod is stuck in Pending, the problem is almost always scheduling, not DNS configuration. Pending means Kubernetes has not successfully placed the pod onto a node yet. So the first question is not "what is wrong with CoreDNS?" It is "why can the scheduler not run this pod anywhere?"

Start With describe pod

The quickest way to understand a pending pod is to inspect its events.

kubectl -n kube-system get pods -l k8s-app=kube-dns
kubectl -n kube-system describe pod <coredns-pod-name>

The events near the bottom usually tell you the real reason, such as:

• insufficient CPU or memory
• untolerated node taint
• no matching node selector or affinity
• no schedulable nodes in the cluster

That event output is more useful than guessing from the word Pending alone.

Common Scheduling Causes

The most frequent cause is simply that the cluster has nowhere valid to place the pod.

On small or new clusters, that often means:

• the only node is tainted as control-plane only
• worker nodes are not ready
• requested resources exceed what the nodes can provide

You can inspect node readiness and capacity with:

kubectl get nodes
kubectl describe nodes

If the nodes are NotReady or heavily constrained, CoreDNS will stay pending along with other unschedulable workloads.

Taints And Tolerations Matter A Lot

Single-node clusters often taint the control-plane node so regular workloads do not schedule there. If you have no worker nodes yet, CoreDNS may stay pending because it does not tolerate the taint.

Check node taints:

kubectl describe node <node-name>

If this is a lab or single-node environment, you may choose to remove the taint so system pods can schedule there.

kubectl taint nodes <node-name> node-role.kubernetes.io/control-plane-

Use that only when it matches your cluster design.

Resource Requests Can Block Scheduling

CoreDNS deployments usually specify CPU and memory requests. If the node cannot satisfy them, the scheduler leaves the pod pending.

Inspect the deployment:

kubectl -n kube-system get deployment coredns -o yaml

If you are running an extremely small lab cluster, you may need to reduce requests carefully.

1resources:
2  requests:
3    cpu: 50m
4    memory: 70Mi

Do this only if you understand the tradeoff. Lowering requests can help scheduling, but it does not create more real capacity.

Check Node Selectors And Affinity Rules

If the CoreDNS deployment or your cluster add-ons use selectors or affinity constraints, the scheduler may reject all nodes even when resources exist.

kubectl -n kube-system get deployment coredns -o yaml | grep -A20 affinity
kubectl -n kube-system get deployment coredns -o yaml | grep -A10 nodeSelector

A wrong node label, stale selector, or strict anti-affinity rule can keep CoreDNS pending indefinitely.

Common Pitfalls

The most common mistake is debugging CoreDNS configuration files while the pod has not even started. A Pending pod has a scheduling problem, not a running DNS problem.

Another issue is ignoring cluster topology. On a fresh single-node cluster, CoreDNS often cannot run because the only node is intentionally tainted.

It is also easy to overlook resource requests in small test clusters. System add-ons still need CPU and memory, even in development environments.

Finally, remember that image-pull failures and container crashes are different states. If the pod is truly Pending, start with the scheduler and node constraints.

Summary

• A Pending CoreDNS pod usually indicates a Kubernetes scheduling problem.
• Use kubectl describe pod to read the exact scheduling failure from events.
• Check node readiness, taints, resource capacity, and affinity rules.
• In small clusters, control-plane taints and limited resources are common causes.
• Do not debug DNS behavior until the CoreDNS pod is actually scheduled and running.