How to Fix Kubernetes ImagePullBackOff

ImagePullBackOff means Kubernetes failed to download a container image and is delaying the next attempt. The pod event normally distinguishes a missing image, authentication failure, network problem, rate limit, or incompatible manifest.

Read the pull event

kubectl describe pod POD -n NAMESPACE
kubectl get events -n NAMESPACE --sort-by=.lastTimestamp

Look for messages such as not found, pull access denied, unauthorized, i/o timeout, too many requests, or no matching manifest.

Verify the exact image reference

kubectl get pod POD -n NAMESPACE -o jsonpath='{.spec.containers[*].image}'

Confirm the registry hostname, repository path, tag, and digest. Avoid relying on mutable latest tags for production releases.

Inspect registry credentials

List the referenced pull secrets without printing their contents:

kubectl get pod POD -n NAMESPACE -o jsonpath='{.spec.imagePullSecrets[*].name}'
kubectl get serviceaccount default -n NAMESPACE -o yaml

Confirm that the Secret exists in the same namespace and uses type kubernetes.io/dockerconfigjson. Do not decode registry credentials into shared terminal logs.

Check node-specific failures

If only some pods fail, identify their nodes:

kubectl get pods -n NAMESPACE -o wide
kubectl describe node NODE

The node may lack registry DNS, proxy configuration, disk space, trusted certificates, or the CPU architecture required by the image.

Diagnose it with Rumus

Diagnose this ImagePullBackOff. Inspect pod events, exact image references, pull
secret names and types, service account configuration, affected nodes, registry
reachability, rate limits, and image architecture. Never print or decode secret
values, and do not modify the workload without approval.

Confirm the fix

Watch the pod after correcting the image or authentication configuration:

kubectl get pods -n NAMESPACE -w
kubectl describe pod POD -n NAMESPACE

The container should move through Pulling and Pulled to Created and Started without another backoff event.