ContainerCreating: The pod is scheduled and the kubelet is setting the container up, but it has not started yet

ContainerCreating means a node has accepted the pod and the kubelet is doing the work before the process starts — pulling the image, attaching volumes, and creating the sandbox. Passing through it is normal; staying in it is not.

Applies to: All Kubernetes versions, any container runtime

What it means

ContainerCreating covers everything the kubelet does between being handed a pod and starting its first process: creating the pod sandbox and its network namespace, asking the CNI plugin for an IP, pulling images that are not cached, and attaching and mounting volumes. On a healthy cluster with a warm image cache this lasts a second or two. When a pod sits here for minutes, one specific step is hanging, and the status string does not say which. The pod's events do — every one of those steps emits an event on failure, so a pod stuck in ContainerCreating with no events is usually a slow image pull, while one with events is usually a volume or network problem.

Most common causes

• A large image being pulled for the first time over a slow link. No error is produced; it is simply not finished.
• A volume that will not attach or mount, which produces FailedAttachVolume or FailedMount events.
• The CNI plugin failing to allocate a pod IP, which produces FailedCreatePodSandBox.
• A secret or ConfigMap mounted as a volume that does not exist — this holds the mount rather than failing container creation outright.
• The container runtime on the node being unresponsive, which shows up as CRI timeouts in the kubelet log.
• A node under disk pressure that cannot write the container's writable layer.

How to diagnose it

1. Read the events first: kubectl describe pod POD. Anything that has actually failed appears there with a reason.
2. If there are no events at all, suspect an image pull. Compare against another pod using the same image on the same node, or check the runtime directly on the node with crictl images.
3. Check how long it has been in this state: kubectl get pod POD -o wide shows age, and the node it landed on.
4. If the pod is on one specific node and others are fine, treat it as a node problem and check the kubelet: journalctl -u kubelet on that node.
5. Check node conditions for disk pressure: kubectl describe node NODE.

How to fix it

1. For slow pulls, pre-pull large images onto nodes, or move them to a registry closer to the cluster. Nothing needs fixing in the pod spec.
2. For volume errors, follow the specific event — an unbound claim, a zone mismatch, or a volume still attached to another node all present here.
3. For sandbox creation failures, check the CNI plugin's daemon set is running and healthy on that node.
4. Create the missing secret or ConfigMap, then delete the pod so it is recreated.
5. If the runtime is unresponsive, restart it on the node and let the pods reschedule.

Notes

A pod can remain in ContainerCreating indefinitely without ever becoming an error state. There is no timeout that converts it into a failure, which is why monitoring for pods that have been in this state for more than a few minutes is worth doing explicitly.

Related

• FailedCreatePodSandBox — The runtime could not create the pod's network sandbox
• FailedMount — A volume could not be mounted into the pod

Sources

• Kubernetes documentation — Pod Lifecycle
• Kubernetes documentation — Debug Pods
• Kubernetes documentation — Images