Fix Kubernetes ContainerCreating Stuck: Step-by-Step Guide

1. Introduction

A Kubernetes pod stuck in ContainerCreating means the kubelet has accepted the pod and is attempting to start it, but something is preventing the container runtime from actually launching the container. Unlike ImagePullBackOff, the image pull may have succeeded. Unlike CrashLoopBackOff, the container hasn't even started yet. This is a setup-time failure, not a runtime failure.

The root cause is almost always one of four things: a volume that can't be mounted, a secret or ConfigMap that doesn't exist or can't be read, a container runtime error on the node, or a network plugin (CNI) that hasn't configured the pod's network namespace. This guide walks through all four paths with exact diagnostic commands.

2. What ContainerCreating Actually Means

When a pod is scheduled to a node, the kubelet goes through several phases before the container starts: pulling the image, creating the container sandbox (network namespace), mounting volumes, injecting secrets and ConfigMaps, then finally starting the container. ContainerCreating means the kubelet is stuck somewhere in this pre-start sequence.

3. Common Causes

• A PersistentVolumeClaim is not bound, or the volume can't be mounted on the node
• A Secret or ConfigMap referenced in envFrom, env.valueFrom, or a volume mount doesn't exist in the namespace
• A projected volume (service account token, downward API) is failing to create
• The container runtime (containerd, Docker) on the node is in a bad state
• The CNI plugin failed to set up the pod's network namespace
• The node has insufficient storage or the image layer extraction failed
• An init container is failing to complete before the main container can start
• A read-only filesystem or permission issue on the node's data directory

4. Step-by-Step Diagnosis and Fix

Step 1: Read the Events section — this is your primary signal

# This is always the first command
kubectl describe pod <pod-name> -n <namespace>

# Scroll to the Events section at the bottom. You will see one of:
#
# "Unable to mount volumes: ... secret "my-secret" not found"
# "MountVolume.SetUp failed: ... timed out waiting for volume"
# "Failed to create pod sandbox: ... CNI plugin not found"
# "Error: ImagePullBackOff" → different problem, see ImagePullBackOff guide
# "Unable to attach or mount volumes: ... PVC not bound"

Step 2: Fix — Missing Secret or ConfigMap

This is the most common cause. The pod spec references a Secret or ConfigMap by name, but it doesn't exist in the pod's namespace.

# Check what secrets the pod expects
kubectl get pod <pod-name> -n <namespace> -o json |   jq '.spec.volumes[], .spec.containers[].env[], .spec.containers[].envFrom[]' 2>/dev/null

# Check whether the referenced secret exists
kubectl get secret <secret-name> -n <namespace>
kubectl get configmap <cm-name> -n <namespace>

# If missing, create it. Example for a generic secret:
kubectl create secret generic <secret-name>   --from-literal=key=value   -n <namespace>

# Note: secrets are namespace-scoped. A secret in the default
# namespace is NOT accessible to a pod in another namespace.

Step 3: Fix — PVC not bound or volume mount failure

# Check PVC status
kubectl get pvc -n <namespace>

# If STATUS is Pending:
kubectl describe pvc <pvc-name> -n <namespace>
# Look for: "waiting for a volume to be created" or StorageClass errors

# Check available StorageClasses
kubectl get storageclass

# If the StorageClass doesn't exist, either create PV manually
# or correct the storageClassName in your PVC spec.

# If volume is bound but mount fails, check node storage:
kubectl describe node <node-name> | grep -A5 "Conditions"

# Force the pod to reschedule to a different node (if volume is zone-locked):
kubectl delete pod <pod-name> -n <namespace>

Step 4: Fix — CNI plugin failure (network namespace setup)

# Events will show: "Failed to create pod sandbox: network plugin is not ready"
# or: "cni plugin not initialized"

# Check the CNI pods on the affected node
kubectl get pods -n kube-system -o wide | grep -E "calico|flannel|weave|cilium|aws-node"

# Describe the CNI pod on the stuck pod's node
kubectl describe pod <cni-pod-name> -n kube-system

# Restart the CNI DaemonSet pod on the affected node (forces re-init):
kubectl delete pod -n kube-system -l k8s-app=aws-node   --field-selector spec.nodeName=<node-name>

# Also check kubelet status on the node itself (if you have SSH access):
systemctl status kubelet
journalctl -u kubelet -n 100 --no-pager

Step 5: Fix — Container runtime issues

# Events will show: "Error response from daemon: ..."
# or: "failed to create containerd task"

# Get the node the pod is on
kubectl get pod <pod-name> -n <namespace> -o wide

# Check for other pods on the same node that are also stuck
kubectl get pods -A --field-selector spec.nodeName=<node-name> | grep ContainerCreating

# If multiple pods on the same node are stuck, the node's container runtime
# or kubelet is the issue — consider draining and restarting the node:
kubectl cordon <node-name>
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data

# After investigation, uncordon the node:
kubectl uncordon <node-name>

Step 6: Fix — Init container not completing

# Check init container status
kubectl get pod <pod-name> -n <namespace>   -o jsonpath='{.status.initContainerStatuses[*]}'

# Example showing stuck init container:
# STATUS column: Init:0/1 or Init:CrashLoopBackOff

# Get init container logs
kubectl logs <pod-name> -n <namespace> -c <init-container-name>

# The init container may be waiting for a dependency (DB, config service)
# that isn't ready. Fix the init container logic or the dependency.

5. Verification Steps

# Watch the pod transition out of ContainerCreating
kubectl get pod <pod-name> -n <namespace> -w

# Expected progression:
# ContainerCreating → Running (1/1)

# Check no events remain
kubectl describe pod <pod-name> -n <namespace> | grep -A20 Events

# Confirm containers are running and healthy
kubectl logs <pod-name> -n <namespace>
kubectl exec -it <pod-name> -n <namespace> -- echo "container is alive"

6. Common Mistakes

• Not reading the Events section — it always contains the exact error message; skipping it wastes time
• Creating secrets in the wrong namespace — secrets are namespace-scoped and a pod cannot access a secret from another namespace
• Assuming the problem is with the image — if kubectl describe pod shows volume or sandbox errors, the image pull already succeeded
• Deleting and recreating the pod without fixing the underlying issue — it will immediately get stuck again
• Not checking whether multiple pods on the same node are affected — node-wide issues require node-level fixes, not pod-level fixes

7. Prevention Tips

• Validate that all referenced Secrets, ConfigMaps, and PVCs exist before deploying — add these checks to your CI/CD pipeline using kubectl apply --dry-run=server
• Use templated deployment manifests to ensure secrets and config names are consistent across environments
• Monitor CNI health on all nodes — a degraded CNI pod silently breaks new pod creation on that node
• Set up node-level alerts for container runtime errors using node_problem_detector or cloud provider node health checks
• For stateful workloads, use volumeClaimTemplates in StatefulSets so PVCs are created automatically with the correct naming
• Test init container logic locally before deploying — an init container that waits indefinitely will block the pod forever

8. FAQ

9. Summary

ContainerCreating means the kubelet is stuck before the container even starts. Always begin with kubectl describe pod and read the Events section — the kubelet or container runtime will tell you exactly what failed.