Why Do Kubernetes Pods Get Stuck? Decoding Common Pod Status Errors

ContainerCreating

This state is not an error; the container is still being created, often due to configuration problems.

1. Docker service issues

When a pod remains in ContainerCreating , checking

kubectl describe pod

may show no errors and the container can be exec'd into, but logs are unavailable. Restarting the Docker service on the node often resolves the issue.

2. Remote storage mount problems (NFS, GFS)

Missing or misconfigured remote storage can cause the pod to hang. Example deployment:

<code>apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx
        imagePullPolicy: Always
        name: nginx
        volumeMounts:
        - mountPath: /tmp/
          name: www
      volumes:
      - name: www
        nfs:
          path: /nfs/web/date
          readOnly: true
          server: 192.168.1.21</code>

The NFS host does not exist, so the pod stays in ContainerCreating .

3. ConfigMap issues

Incorrect ConfigMap names or mounting failures can also cause the pod to be stuck.

<code>apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx
        imagePullPolicy: Always
        name: nginx
        volumeMounts:
        - mountPath: /tmp/
          name: www
      volumes:
      - name: www
        configMap:
          name: nginx-config</code>

Fix by correcting the ConfigMap name or ensuring it exists.

ErrImagePull / ImagePullBackOff

1. Image repository problems

Image pull failures often stem from missing images in the repository, especially when CI/CD pipelines push images while the registry is being cleaned.

<code>apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1111111111  # non‑existent image
        imagePullPolicy: Always
        name: nginx
        volumeMounts:
        - mountPath: /tmp/
          name: www
      volumes:
      - name: www
        configMap:
          name: nginx-config</code>

2. startContainer failures

These can appear after Docker binary updates that break container startup.

Pending

Common reasons for the Pending state include:

Scheduler component failures or cluster component crashes.

Missing or insufficient ServiceAccount permissions.

Incorrect node selector, tolerations, or taints.

Insufficient node resources.

Persistent volume problems.

CrashLoopBackOff / ERROR

Typical causes are:

Misconfiguration of the container runtime causing immediate crashes.

Failed health‑check probes that kill the container.

Startup scripts that encounter network or DNS issues.

Resource limits too low, leading to OOM kills.

Terminating or Unknown

These states often result from large‑scale node failures or network interruptions causing many pods to enter Terminating . Force‑deleting the pods usually resolves the issue.

UnexpectedAdmissionError

This error indicates that a node’s disk is full, preventing log writes. Identify affected pods, clean up the node’s filesystem, and delete the problematic pods, e.g.:

<code>kubectl get pods -A | grep UnexpectedAdmissionError | awk '{print("kubectl delete pod ", $2, " -n ", $1)}' | /bin/bash</code>

Linux issues mistaken for Kubernetes problems

When a node becomes NotReady and

df -h

hangs, the underlying cause may be a failed NFS mount.

Example remediation:

<code>// Deploy NFS service
echo "/home/nfs  *(rw,async,no_root_squash)" >> /etc/exports
systemctl start nfs

// On client
mkdir -p /tmp/test1/
mount -t nfs 10.0.16.16:/home/nfs /tmp/test1/
df -h | grep /tmp/test1</code>

If

df -h

is blocked, stop the NFS service to reproduce the issue, then use

mount -l | grep nfs

to locate the problematic mount and restart the NFS server.