🚨 Kubernetes Error Guide: 'Failed to create pod sandbox' Sandbox & CNI Failures

Exact Error Message

FailedCreatePodSandBox means the container runtime could not create the pod’s sandbox (the pause container plus its network namespace) before any application container can start. You will see it in pod events:

Events:
  Type     Reason                  Age   From     Message
  ----     ------                  ----  ----     -------
  Normal   Scheduled               40s   default  Successfully assigned prod/web-6d8c9f7b5c-q4n2t to node-2
  Warning  FailedCreatePodSandBox  38s   kubelet  Failed to create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "a3f1...": failed to set up pod "web-6d8c9f7b5c-q4n2t_prod" network: networkPlugin cni failed to set up pod "web-6d8c9f7b5c-q4n2t_prod" network: plugin type="calico" failed (add): error getting ClusterInformation: connection is unauthorized

Two common variants — a missing pause image and missing CNI binaries:

Failed to create pod sandbox: rpc error: code = Unknown desc = failed to get sandbox image "registry.k8s.io/pause:3.9": failed to pull image "registry.k8s.io/pause:3.9": failed to resolve reference: dial tcp: lookup registry.k8s.io: no such host

Failed to create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container network: networkPlugin cni failed to set up pod network: failed to find plugin "bridge" in path [/opt/cni/bin]

What the Error Means

Before any container in a pod runs, the kubelet asks the CRI to build a sandbox: it pulls the pause image, starts the pause container to hold the pod’s network namespace, then invokes the configured CNI plugin to attach the pod to the cluster network and assign an IP. FailedCreatePodSandBox means one of those steps failed, so the pod never reaches Running and stays in ContainerCreating.

The two failure families are visible in the message:

• failed to get sandbox image "registry.k8s.io/pause:3.x" — the runtime cannot fetch the pause image (network, DNS, or air-gap).
• networkPlugin cni failed to set up pod ... network — the CNI plugin failed: not installed, not ready, misconfigured, or out of IPs.

Common Causes

• CNI not ready or misconfigured. The CNI DaemonSet (Calico, Cilium, Flannel) has not finished installing, or its config in /etc/cni/net.d/ is missing or wrong.
• Missing pause image. The node cannot pull registry.k8s.io/pause:3.x (air-gapped, DNS failure, or wrong sandbox_image in containerd config).
• CNI plugin binaries missing. The plugin referenced in the CNI config (bridge, calico, portmap) is absent from /opt/cni/bin.
• containerd / CRI socket issues. The kubelet cannot reach /run/containerd/containerd.sock, or containerd is unhealthy.
• IP address exhaustion. The node’s pod CIDR or the IPAM pool has no free addresses, so the CNI cannot assign an IP.
• Cgroup driver mismatch. The kubelet and containerd disagree on systemd vs cgroupfs, breaking sandbox creation.

How to Reproduce the Error

On a fresh node, taint or delete the CNI DaemonSet so no plugin config exists, then schedule a pod:

apiVersion: v1
kind: Pod
metadata:
  name: sandbox-test
  namespace: prod
spec:
  containers:
    - name: app
      image: nginx:1.27

kubectl delete ds -n kube-system calico-node   # remove CNI on the node
kubectl apply -f sandbox-test.yaml
kubectl describe pod sandbox-test -n prod | grep -A4 Events

The pod sticks in ContainerCreating with FailedCreatePodSandBox because no CNI config exists in /etc/cni/net.d/.

Diagnostic Commands

# Confirm the pod is stuck and read the sandbox error
kubectl get pod sandbox-test -n prod -o wide
kubectl describe pod sandbox-test -n prod | grep -A6 Events

# Inspect sandboxes and the runtime from the node
crictl pods
crictl info | grep -i 'sandboxImage\|cni'

# Confirm the CNI config and plugin binaries are present
ls -l /etc/cni/net.d/
ls -l /opt/cni/bin/

# Runtime and kubelet logs (where the real CNI/sandbox error appears)
journalctl -u containerd -n 100 --no-pager | grep -i 'sandbox\|cni\|pause'
journalctl -u kubelet -n 100 --no-pager | grep -i 'FailedCreatePodSandBox\|cni'

# CNI plugin (e.g. Calico/Cilium) pod and its on-node logs
kubectl get pods -n kube-system -l k8s-app=calico-node -o wide
ls -l /var/log/calico/cni/ 2>/dev/null

# Verify the pause image is present and the cgroup driver matches
crictl images | grep pause
grep -i 'SystemdCgroup\|cgroupDriver' /etc/containerd/config.toml /var/lib/kubelet/config.yaml

Step-by-Step Resolution

1. Read the message to pick the family. failed to get sandbox image is a pause-image problem; networkPlugin cni failed is a CNI problem.

2. For a missing pause image, pull it on the node (or point containerd at a reachable mirror) and confirm the configured sandbox_image:

   crictl pull registry.k8s.io/pause:3.9
   grep sandbox_image /etc/containerd/config.toml
   systemctl restart containerd

3. For CNI not ready, confirm the CNI DaemonSet is healthy and its config landed:

   kubectl get pods -n kube-system -l k8s-app=calico-node
   ls /etc/cni/net.d/    # expect e.g. 10-calico.conflist

   If the DaemonSet is crashlooping, fix it first — it writes the config and binaries every node needs.

4. For missing plugin binaries, install the CNI plugins into /opt/cni/bin (the standard plugins package or the CNI vendor’s installer DaemonSet provides bridge, portmap, loopback, etc.).

5. For IP exhaustion, check the IPAM pool and free up or expand it:

   kubectl describe node node-2 | grep -i podCIDR
   calicoctl ipam show --show-blocks   # Calico example

6. For a cgroup-driver mismatch, set both kubelet and containerd to systemd and restart:

   # containerd: SystemdCgroup = true ; kubelet: cgroupDriver: systemd
   systemctl restart containerd kubelet

7. Recreate the pod so the kubelet retries sandbox creation:

   kubectl delete pod sandbox-test -n prod

Prevention and Best Practices

• Verify the CNI DaemonSet is Ready on every node before scheduling workloads; CNI must be installed first on new nodes.
• Mirror registry.k8s.io/pause into your private registry and set sandbox_image to the mirror so air-gapped nodes never fail to fetch it.
• Keep /opt/cni/bin populated by the CNI installer DaemonSet and validate its contents during node bootstrap.
• Standardize the cgroup driver (systemd) across kubelet and containerd in your node image to avoid silent mismatches.
• Monitor IPAM pool utilization and alert before pod CIDRs exhaust, which manifests as intermittent sandbox failures. See more in Kubernetes & Helm guides.

Related Errors

• Kubernetes Error: networkPlugin cni failed to set up pod — the dedicated deep dive on the CNI half of this error.
• Kubernetes Error: Failed to pull image (CRI / containerd) — relevant when the sandbox fails specifically because the pause image cannot be pulled.

Frequently Asked Questions

What is a pod sandbox in Kubernetes? The sandbox is the pause container and the network namespace it holds for a pod. The runtime creates it first, attaches it to the network via CNI, then starts your application containers inside that namespace.

Why does my pod stay in ContainerCreating with FailedCreatePodSandBox? The runtime could not finish building the sandbox — usually the CNI plugin failed to assign networking or the pause image could not be pulled. No app container starts until the sandbox succeeds.

How do I fix “failed to get sandbox image pause”? Pull registry.k8s.io/pause:3.x on the node with crictl pull, or point containerd’s sandbox_image at a reachable mirror, then restart containerd. This is common in air-gapped clusters.

What does “failed to find plugin bridge in path /opt/cni/bin” mean? The CNI config references a plugin binary that is not installed. Install the CNI plugin binaries into /opt/cni/bin, typically via your CNI provider’s installer DaemonSet.

Can a cgroup driver mismatch cause FailedCreatePodSandBox? Yes. If the kubelet uses systemd and containerd uses cgroupfs (or vice versa), sandbox creation fails. Set both to systemd and restart the services.