FailedCreatePodSandBox: The runtime could not create the pod's network sandbox

Every pod gets a sandbox holding its network namespace and IP before any container starts. When creating it fails, the pod never leaves ContainerCreating, and the cause is nearly always the CNI plugin.

Applies to: All Kubernetes versions, any container runtime

What it means

The pod sandbox is the container that owns the pod's network namespace, and creating it involves the runtime calling the CNI plugin to allocate an IP and wire up the interface. FailedCreatePodSandBox is emitted when that fails, and the message usually carries the CNI plugin's own error, which is far more specific than the Kubernetes-level wording. The common families are: the CNI configuration is missing or invalid on that node, the plugin's IP address pool is exhausted, the plugin's daemon is not running, or the plugin cannot reach the control plane component it depends on. Because this happens before any container starts, there are no application logs — the evidence is entirely in events and on the node.

Most common causes

• No CNI configuration present on the node, so the runtime has no plugin to call.
• The CNI plugin's DaemonSet is not running on that node, or is crash-looping.
• IP address exhaustion in the node's allocated pod CIDR — more pods scheduled than addresses available.
• Stale network namespace or IPAM state left behind by pods that did not clean up, holding addresses that are no longer in use.
• The CNI plugin cannot reach its own datastore or the API server.
• A mismatch between the cluster's configured pod CIDR and the plugin's configuration.
• The runtime cannot pull the pause image used for the sandbox, often in an air-gapped cluster with an unmirrored registry.

How to diagnose it

1. Read the full event: kubectl describe pod POD. The CNI's own error text is the useful part.
2. Check the CNI DaemonSet on that node: kubectl get pods -n kube-system -o wide | grep NODE.
3. Look for IPAM exhaustion — messages mentioning no IP addresses available in range set are unambiguous.
4. Count running pods on the node against the size of its pod CIDR.
5. Check the CNI configuration exists on the node under /etc/cni/net.d.
6. Confirm the pause image is present or pullable: crictl images | grep pause.

How to fix it

1. Restore the CNI plugin on the node — reinstall its configuration, or fix the DaemonSet so it schedules and stays healthy there.
2. For IP exhaustion, enlarge the per-node CIDR, reduce the pods-per-node limit, or add nodes. Some plugins support allocating additional blocks per node.
3. Clear stale IPAM state according to the plugin's documented procedure, if addresses are held by pods that no longer exist.
4. Mirror the pause image into the registry the cluster can reach in air-gapped environments.
5. Align the plugin's pod CIDR configuration with the cluster's.

Notes

IP exhaustion on a node is a slow-building failure: the cluster works normally until a node crosses its address limit, and only new pods on that specific node fail. The pattern of a single node rejecting all new pods while the rest of the cluster is fine is the signature.

Related

• ContainerCreating — The kubelet is still preparing the container
• network plugin is not ready — The node has no usable CNI configuration

Sources

• Kubernetes documentation — Network Plugins
• Kubernetes documentation — Cluster Networking
• Kubernetes documentation — Debug Pods