Introduction

When CoreDNS is stuck in ContainerCreating, the cluster usually has a lower-level node, image, storage, or networking problem rather than a CoreDNS logic problem. Because CoreDNS is critical for service discovery, this failure can quickly ripple into broader cluster symptoms, so the fastest path is to inspect pod events and node conditions first.

Start With Pod Describe and Events

ContainerCreating means the pod object exists, but the kubelet has not completed container startup yet. The best first step is to inspect the pod events.

kubectl get pods -n kube-system
kubectl describe pod -n kube-system coredns-abc123
kubectl get events -n kube-system --sort-by=.lastTimestamp

The describe output usually tells you whether the kubelet is waiting on image pulls, volume setup, sandbox creation, or network plugin readiness.

Common Causes

CoreDNS stuck in ContainerCreating often comes from one of these categories:

• image pull failures,
• CNI or pod sandbox creation issues,
• node disk or resource pressure,
• volume or secret mount problems,
• kubelet or container runtime failures.

For CoreDNS specifically, networking issues are especially common because the pod depends on a working pod network and kube-system components being healthy.

Check Node and Runtime Health

If the pod never gets to the point where logs are available, inspect the node that is supposed to run it.

kubectl get pod -n kube-system -o wide
kubectl describe node <node-name>
kubectl get nodes

Look for warning conditions such as disk pressure, network plugin failures, or repeated container runtime errors. If the node cannot create pod sandboxes correctly, CoreDNS will sit in ContainerCreating along with other affected workloads.

Image Pull and Registry Problems

If events show ErrImagePull, ImagePullBackOff, or registry timeouts, the issue is not the CoreDNS manifest itself. It is image availability or node egress.

Typical checks:

kubectl describe pod -n kube-system coredns-abc123
kubectl get events -n kube-system --sort-by=.lastTimestamp

Then confirm:

• the image reference is valid,
• nodes can reach the registry,
• image pull secrets are correct if needed,
• the container runtime is healthy.

CNI and Sandbox Creation Problems

If events mention sandbox creation or network setup failure, the cluster network plugin is a likely suspect. CoreDNS depends on pod networking, so if the CNI plugin is broken, CoreDNS often becomes one of the visible casualties.

Check the CNI-related pods and kubelet messages:

kubectl get pods -n kube-system -o wide
kubectl describe pod -n kube-system <cni-pod-name>

Many "CoreDNS is broken" incidents are really "the node cannot attach the pod network."

ConfigMap and Logs Come Later

People often jump straight to the CoreDNS ConfigMap. That is useful only after the container is actually running or crash-looping. A pod stuck in ContainerCreating usually has not reached the point where CoreDNS configuration is even being exercised.

Once it starts, then it makes sense to inspect:

kubectl get configmap coredns -n kube-system -o yaml
kubectl logs -n kube-system coredns-abc123

Until then, focus on kubelet, node, and event-level causes.

Common Pitfalls

• Looking at CoreDNS application logic before checking pod events.
• Assuming ContainerCreating means a DNS configuration error instead of a node startup problem.
• Ignoring CNI health even though sandbox and network setup are frequent causes.
• Trying to read pod logs before the container has actually started.
• Troubleshooting only CoreDNS when multiple kube-system pods are failing on the same node.

Summary

• 'ContainerCreating usually points to startup dependencies such as image pulls, networking, or node health.'
• Start with kubectl describe pod and recent events in kube-system.
• Check the hosting node and container runtime if the pod never starts.
• CNI failures are a common root cause for CoreDNS startup problems.
• Inspect CoreDNS logs and ConfigMap only after the container is able to run.