Cloud Native 9 min read

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

Learn how to diagnose and resolve frequent Kubernetes pod status issues such as ContainerCreating, ErrImagePull, Pending, CrashLoopBackOff, and UnexpectedAdmissionError by examining Docker services, storage mounts, ConfigMaps, image repositories, and node resources, with practical examples and command‑line solutions.

Efficient Ops
Efficient Ops
Efficient Ops
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:

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

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.

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

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.

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

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.:

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

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:

// 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

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.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

OperationsKubernetesNFSConfigMapPod troubleshootingContainerCreatingErrImagePull
Efficient Ops
Written by

Efficient Ops

This public account is maintained by Xiaotianguo and friends, regularly publishing widely-read original technical articles. We focus on operations transformation and accompany you throughout your operations career, growing together happily.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.