☸️ Kubernetes Error Guide: 'failed to reserve container name' Containerd Stuck Sandbox

Overview

When a pod is stuck in ContainerCreating and the events show a name-reservation failure, the kubelet and containerd are disagreeing about container state:

Warning  Failed  kubelet  Error: failed to reserve container name
"nginx_web-7d9f_default_5c2b1a9e-4f3d-11ef-9a2c-0242ac110002_0":
name "nginx_web-7d9f_default_5c2b1a9e-4f3d-11ef-9a2c-0242ac110002_0" is reserved for "a3f9c1..."

containerd maintains an in-memory registry of container and sandbox names so that two containers cannot share one identity. When the kubelet asks it to create a container, containerd first reserves the name. If that name is already reserved — because a previous create attempt for the same pod did not fully complete, a sandbox is stuck, or a duplicate create raced — the reservation fails and the pod cannot start.

This is a stuck-state problem in the container runtime, not a bad image or manifest. The pod is usually healthy in the API server; containerd is simply holding a stale reservation that must be cleared, typically by removing the orphaned container/sandbox or restarting the runtime.

Symptoms

• Pod stuck in ContainerCreating, sometimes for many minutes.
• kubectl describe pod shows repeated failed to reserve container name ... is reserved for ....
• crictl ps -a shows a container in an odd state (Created but never Running) for that pod.
• Restarting the pod does not help because the reservation persists in containerd.
• Often appears after a node reboot, a kubelet crash, or an out-of-disk event mid-create.

Common Root Causes

1. A previous create attempt did not finish

The kubelet started creating the container/sandbox, then the create was interrupted (OOM, disk full, kubelet restart). containerd kept the name reserved but never completed the container.

2. A stuck or orphaned pod sandbox

The pod’s sandbox (pause container) is in a half-created state. Because the sandbox owns the name namespace, new container creation for that pod keeps colliding.

3. Duplicate/racing create requests

Rapid delete-and-recreate of the same pod, or a kubelet that retried aggressively, issued overlapping creates for the same name.

4. containerd metadata out of sync with the kubelet

After a crash, containerd’s on-disk state and the kubelet’s expected state diverge; the reservation exists with no corresponding running container.

5. Disk pressure during creation

An imagefs-full event mid-create leaves partial container state and a dangling reservation.

Diagnostic Workflow

Step 1: Identify the stuck pod and node

kubectl get pods -o wide | grep ContainerCreating
kubectl describe pod <pod> | grep -A2 "reserve container name"

Step 2: List containers and sandboxes on the node with crictl

sudo crictl ps -a | grep <pod-name>
sudo crictl pods | grep <pod-name>

Step 3: Inspect the offending container/sandbox state

sudo crictl inspect <container-id> | grep -i state
sudo crictl inspectp <sandbox-id> | grep -i state

Step 4: Check the runtime and kubelet logs for the interruption

sudo journalctl -u containerd --no-pager | grep -i "reserve" | tail
sudo journalctl -u kubelet --no-pager | grep -i "<pod-name>" | tail

Step-by-Step Resolution

1. Confirm the pod is otherwise healthy in the API. If the Deployment/manifest is fine and only containerd is stuck, this is a runtime-state cleanup, not a redeploy.

2. Remove the stuck container holding the name. Find the container ID for the pod and force-remove it so containerd releases the reservation:

sudo crictl ps -a | grep <pod-name>
sudo crictl rm -f <container-id>

3. Remove the orphaned sandbox if it is stuck. Stop and remove the pod sandbox so the whole name namespace clears:

sudo crictl pods | grep <pod-name>
sudo crictl stopp <sandbox-id>
sudo crictl rmp <sandbox-id>

4. Let the kubelet recreate the pod. With the reservation gone, the kubelet’s next sync recreates the sandbox and container cleanly. Watch it progress:

kubectl get pod <pod> -w

5. If names are still reserved after cleanup, restart containerd, then the kubelet. This flushes containerd’s in-memory reservation table:

sudo systemctl restart containerd
sudo systemctl restart kubelet

6. Verify the pod reaches Running:

kubectl get pod <pod>

nginx-web-7d9f   1/1   Running   0   45s

7. Address the underlying trigger (disk pressure, node instability) so the interrupted-create condition does not recur.

Prevention

• Keep nodes off DiskPressure; interrupted creates from a full imagefs are a leading cause of stuck reservations.
• Avoid rapid delete/recreate loops on the same pod name; let the kubelet finish reconciling before retrying.
• Monitor kubelet and containerd restarts, which correlate with orphaned sandboxes.
• Keep containerd and the kubelet patched; several stuck-sandbox races are fixed in newer releases.
• Use liveness/readiness probes and controlled rollouts rather than manual force-deletes that can race create/delete.

Related Errors

• failed to create containerd task: ... already exists — a related duplicate-identity failure at the task layer.
• context deadline exceeded on sandbox creation — a stuck sandbox timing out during create.
• pod sandbox changed, it will be killed and re-created — the kubelet recycling a broken sandbox.
• Failed to create pod sandbox: ... network is not ready — a CNI issue that can also strand sandboxes.

Frequently Asked Questions

What does name is reserved for mean in containerd? containerd reserves a unique name before creating a container. The error means that name is already held by a prior, incomplete create attempt, so the new container cannot claim it until the stale reservation is cleared.

How do I clear a stuck container name? Find the container or sandbox for the pod with crictl ps -a/crictl pods, then force-remove it (crictl rm -f, crictl rmp). The kubelet recreates the pod cleanly once the reservation is released.

Do I need to restart containerd? Only if removing the stuck container and sandbox does not release the name. Restarting containerd flushes its in-memory reservation table; restart the kubelet afterward. The DevOps AI prompt library has prompts for scripting safe node runtime recovery.

Will deleting the pod fix it? Not always. The reservation lives in containerd on the node, so recreating the pod can hit the same reserved name. Clear the runtime state first, then let the pod recreate.

What causes this in the first place? An interrupted container create — from a kubelet/containerd crash, node reboot, or disk-pressure event mid-creation — leaves a reserved name with no running container. Keeping nodes stable and off DiskPressure prevents it. For more, see the Kubernetes & Helm guides.