failed to reserve container name: A container with that name already exists in the runtime's state

The runtime keeps container names unique. This error means a previous container with the same name was not cleaned up, so the new one cannot be created.

Applies to: Clusters using containerd or CRI-O

What it means

Container runtimes derive a name for each container from the pod, the container, and an attempt counter, and they reserve it before creating. failed to reserve container name … name is reserved for … means a container with that identity is still known to the runtime. Usually the previous instance was not fully removed — the kubelet or the runtime restarted mid-operation, or a cleanup failed — leaving state behind that blocks the replacement. The kubelet retries, so this often clears by itself once the runtime finishes its own garbage collection, and it becomes a real problem only when the stale entry cannot be removed.

Most common causes

• A previous container that failed to be removed cleanly, leaving a reservation behind.
• The kubelet or the runtime restarting during container creation or deletion.
• A stuck container that the runtime cannot stop, so its name is never released.
• Disk pressure preventing the runtime from completing cleanup.
• A runtime bug or an inconsistent state directory after an unclean shutdown.

How to diagnose it

1. List containers the runtime knows about, including stopped ones: crictl ps -a on the node.
2. Look for a container matching the reserved name that should not exist.
3. Read the runtime log for the failed cleanup: journalctl -u containerd.
4. Check whether the node is under disk pressure, which prevents cleanup.
5. Check whether the kubelet or the runtime restarted around the time the problem began.

How to fix it

1. Wait briefly — the kubelet retries and the runtime's garbage collection often resolves it without intervention.
2. Remove the stale container on the node: crictl rm CONTAINER_ID.
3. Free disk space if cleanup is blocked by it.
4. Restart the container runtime to clear inconsistent state, draining the node first where possible.
5. Delete and recreate the pod so it gets a fresh identity if the stale name cannot be released.

Notes

Because the kubelet retries indefinitely, a pod can sit in ContainerCreating on this error without ever failing outright. It is worth checking explicitly on any pod that has been creating for more than a couple of minutes.

Related

• CreateContainerError — The runtime failed to create the container
• ContainerCreating — The kubelet is still preparing the container

Sources

• Kubernetes documentation — Container Runtime Interface
• Kubernetes documentation — Debugging Kubernetes nodes with crictl
• containerd CRI plugin configuration