Skip to content
Intellira
Get early access
Kubernetesmedium severity

ContainerCreating

A Pod stuck in ContainerCreating is waiting on a volume, image pull, secret, or network attachment. Here is how to find which one and fix it.

Written by Intellira Engineering, Editorial team

What ContainerCreating means

ContainerCreating is a normal, transient phase: the Pod has been scheduled to a node and the kubelet is pulling images, mounting volumes and secrets, and asking the CNI plugin to set up networking before it starts the container. The problem is not the status itself — it is a Pod that stays in ContainerCreating instead of moving on to Running.

Because no container exists yet, kubectl logs is useless here. Everything you need is in the Pod's events — and the first Warning event points at the root cause.

Two scopes matter when you read those events. A container-level problem (image, secret, this Pod's volume) affects only this Pod. A node-level or cluster-level problem (CNI plugin down, IP exhaustion, a CSI driver missing on the node) affects every Pod that lands on the same node — fix the node, not the workload.

Diagnose it

kubectl get pod <pod> -n <namespace> -o wide
kubectl describe pod <pod> -n <namespace>

Events expire from the API server after about an hour, so capture them promptly. The Events section will point at one of the categories below. Match the message:

# Image pull
Failed to pull image "...": rpc error: ... 401 Unauthorized
Back-off pulling image "..."

# PVC / volume attach
Unable to attach or mount volumes: unmounted volumes=[data]
AttachVolume.Attach failed for volume "pvc-..."
Multi-Attach error for volume "pvc-..." Volume is already exclusively attached to one node

# Secret / ConfigMap mount
MountVolume.SetUp failed for volume "..." : secret "..." not found

# Network (CNI) sandbox
FailedCreatePodSandBox ... networkPlugin cni failed to set up pod ... failed to assign an IP address

If the volume is involved, the failing event is often recorded against the node or the PVC rather than the Pod:

kubectl get pvc -n <namespace>
kubectl describe pvc <claim> -n <namespace>
kubectl get events -n <namespace> --sort-by=.lastTimestamp

Note

Use kubectl get events --sort-by=.lastTimestamp when the Pod's own event list has rolled over. Volume attach failures and CNI errors are often recorded against the node or the PVC rather than the Pod.

Causes, and how to fix each

Each mechanism below is independent. Identify which event you have, then apply only that fix.

1. Image pull

The kubelet cannot fetch the image: a wrong tag, a private registry with no imagePullSecret, or registry rate limiting (Back-off pulling image). This is the most common cause of a Pod stuck before start.

  • Diagnose: the event reads Failed to pull image or Back-off pulling image. A 401/403 means auth; not found/manifest unknown means a bad tag or repository.
  • Fix: verify the tag exists in the registry. For private registries, attach an imagePullSecret to the Pod (directly or via its ServiceAccount). For rate limits, authenticate to the registry or use a pull-through cache.

2. PVC unbound

The Pod references a PVC that never bound to a PersistentVolume — no matching PV, or no StorageClass to dynamically provision one.

  • Diagnose: kubectl get pvc shows Pending, and the event reads unmounted volumes=[...]. kubectl describe pvc shows why provisioning failed.
  • Fix: confirm a StorageClass exists and can provision, or create a matching PV. The PVC must reach Bound before the Pod can mount it.

3. Multi-Attach — volume stuck on a prior node

A ReadWriteOnce volume can only be mounted read-write by a single node. After a node failure, the old VolumeAttachment can linger, so the new node cannot attach the disk.

  • Diagnose: the event reads Multi-Attach error for volume. Check the attachment object: kubectl get volumeattachment. The volume is still bound to the dead/old node.
  • Fix: let the original Pod terminate so the attachment is released. If the old node is gone for good, the stale VolumeAttachment must be cleared before the new node can attach. For single-writer correctness, consider ReadWriteOncePod, which restricts the volume to one Pod.

4. Volume zone / topology mismatch

A block volume (EBS, GCE PD) lives in one availability zone; if the Pod is scheduled to a node in a different zone, the attach fails.

  • Diagnose: the attach event names the volume but the disk cannot reach the node. Compare the node's zone label with the volume's zone.
  • Fix: use a StorageClass with volumeBindingMode: WaitForFirstConsumer so the volume is provisioned in the zone the Pod is scheduled to, rather than provisioned first and stranded.

5. Missing Secret or ConfigMap

This is not a PVC failure. The Pod mounts a Secret or ConfigMap that does not exist, or exists in a different namespace.

  • Diagnose: the event reads MountVolume.SetUp failed for volume "..." : secret "..." not found (or configmap ... not found).
  • Fix: create the referenced object in the same namespace as the Pod (Secrets are namespaced); fix any typo in the secretName/name field. The kubelet retries the mount automatically once the object exists.

6. CNI cannot set up the network sandbox

The CNI plugin assigns the Pod IP and wires up networking. If it is unhealthy or the subnet is out of IPs, the sandbox never comes up. This is a node/cluster problem, not a workload problem.

  • Diagnose: the event reads FailedCreatePodSandBox ... networkPlugin cni failed to set up pod or failed to assign an IP address. Check the CNI daemonset: kubectl get pods -n kube-system (e.g. Calico, Cilium, Flannel, or the cloud CNI). A freshly joined node can take 30-60s for its CNI pod to write config.
  • Fix: restore the CNI daemonset on the node, or free IP addresses in the subnet if the pool is exhausted. Because the failure is per-node, every Pod scheduled there is affected.

7. CSI driver node plugin missing

A CSI volume needs the driver's node plugin running on the target node. If that DaemonSet pod is missing (wrong nodeSelector/toleration, or crashed), the mount hangs even when the PVC is Bound.

  • Diagnose: the PVC is Bound, but the mount still fails on this node. Confirm the CSI node DaemonSet is running there: kubectl get pods -n kube-system -o wide | grep csi.
  • Fix: get the CSI node DaemonSet scheduled onto the node (tolerations/nodeSelector), or reschedule the Pod to a node where the driver is healthy.

8. Init container not finishing (related state)

If the Pod uses init containers, it shows Init:X/Y rather than ContainerCreating — but the init container itself can sit in ContainerCreating for any reason above. App containers do not start until all init containers complete.

  • Diagnose: status is Init:0/1. kubectl describe pod shows which init container is blocked and why (its own image, volume, or secret).
  • Fix: resolve the init container's blocker; the app containers proceed automatically once all init containers run to completion.

Fix it

  1. Run kubectl describe pod and read the first Warning event.
  2. Classify it: image, PVC, multi-attach, zone, secret/configmap, CNI sandbox, or CSI node plugin.
  3. Decide the scope. Image/secret/this-PVC are container-level — fix the workload. CNI/IP-exhaustion/CSI-node-plugin are node-level — fix the node, and expect other Pods on it to be affected too.
  4. Apply the single matching fix above. The kubelet retries mounts and pulls automatically; you rarely need to delete the Pod.
  5. Delete the Pod only if it does not advance within a minute after the dependency is resolved.

How Intellira diagnoses this

Intellira pulls the Pod's events through the Kubernetes MCP server and classifies the stall — image, PVC, multi-attach, secret/configmap, CNI sandbox, or CSI node plugin — on the first pass, then follows the chain. For a volume stall it inspects the PVC binding and the node's VolumeAttachment objects; for a secret stall it checks whether the referenced object exists in the Pod's namespace; for a CNI stall it correlates against the health of the network daemonset rather than blaming your workload. It also separates container-level from node-level causes, so you know whether to fix the Pod or the node. You get the actual blocking dependency, not just the word "ContainerCreating."

Sources

By Intellira Engineering. AI-assisted draft, reviewed by the Intellira engineering team; claims cited inline; last verified 2026-06-02.

Frequently asked questions

How long is "too long" to sit in ContainerCreating?
A normal Pod reaches Running within a few seconds to a minute, dominated by image pull time. If a Pod is still ContainerCreating after 2-3 minutes, it is stuck on a dependency — a volume that will not attach, a secret that does not exist, an image that will not pull, or a CNI plugin that cannot allocate a network sandbox.
Why does kubectl logs return nothing?
There is no container yet, so there are no logs to stream. While a Pod is in ContainerCreating the container has not started, so all diagnosis must come from kubectl describe events, not from logs.
Can a missing PersistentVolume cause this?
Yes. If a PVC is unbound or the backing volume cannot attach to the node (wrong availability zone, volume already attached elsewhere, or CSI driver error), the kubelet reports FailedAttachVolume/FailedMount and the Pod stays in ContainerCreating until the volume becomes available.

Related errors

Find the root cause of ContainerCreating on your stack

Connect read-only and Intellira correlates the change behind it across Bitbucket, Jenkins, ArgoCD and Kubernetes — with the evidence to prove it.

Get early accessBook a demo