ErrImagePull is the initial failure when Kubernetes cannot pull a container image. It immediately precedes ImagePullBackOff and indicates authentication, network, or image reference problems.
ErrImagePull is the immediate error state when the kubelet fails to pull a container image from a registry. This is distinct from ImagePullBackOff, which represents the retry grace period that follows. Both errors indicate the same underlying issue—the image cannot be retrieved. When you see ErrImagePull, Kubernetes has just attempted a pull and failed. After this initial failure, the status transitions to ImagePullBackOff as Kubernetes waits before retrying. The error details in pod events reveal whether it's an authentication issue, network problem, or missing image.
Get the specific error message that explains why the pull failed:
kubectl describe pod <pod-name>In the Events section, look for messages containing "Failed to pull image". Common messages include:
- "manifest unknown" - image or tag doesn't exist
- "unauthorized" - authentication required
- "connection refused" - network issue
Check your pod or deployment spec for the exact image reference:
kubectl get pod <pod-name> -o jsonpath='{.spec.containers[*].image}'Verify the image exists by pulling it locally:
docker pull your-registry/image:tagEnsure the registry URL, image name, and tag are all correct.
Verify a pull secret exists and is referenced in the pod:
# List secrets in the namespace
kubectl get secrets
# Check if pod references the secret
kubectl get pod <pod-name> -o jsonpath='{.spec.imagePullSecrets}'If missing, create the secret and update your deployment:
kubectl create secret docker-registry myregistry \
--docker-server=<registry> \
--docker-username=<user> \
--docker-password=<token>Launch a debug pod to test network access:
kubectl run debug --rm -it --image=curlimages/curl -- sh
# Test registry access
curl -v https://your-registry.com/v2/If this fails, check:
- DNS resolution for the registry hostname
- Firewall rules allowing outbound HTTPS
- Network policies that might block egress
Decode and verify the secret contains correct credentials:
kubectl get secret myregistry -o jsonpath='{.data.\.dockerconfigjson}' | base64 -dTest the credentials work:
docker login <registry> -u <username> -p <password>
docker pull <image>Recreate the secret if credentials have expired or changed.
Tags can be moved or deleted. For production, consider using immutable digests:
image: myregistry/myapp@sha256:abc123def456...Get the digest for an image:
docker inspect --format='{{index .RepoDigests 0}}' myimage:tagDigests guarantee you get the exact image version you tested.
For multi-node clusters, remember that images are pulled per-node. If using imagePullPolicy: IfNotPresent, the image might exist on some nodes but not others, causing inconsistent failures.
With containerd as the runtime (default in newer Kubernetes), registry configuration is handled differently than Docker. Ensure registry mirrors and credentials are configured in containerd's config.toml on each node.
For EKS, nodes need IAM permissions for ECR. For GKE, verify Workload Identity configuration. For AKS, use the built-in ACR integration.
Avoid using the 'latest' tag in production—it causes unpredictable behavior and makes rollbacks difficult. Pin to specific versions or use digests.
Failed to connect to server: connection refused (HTTP/2)
How to fix "HTTP/2 connection refused" error in Kubernetes
missing request for cpu in container
How to fix "missing request for cpu in container" in Kubernetes HPA
error: invalid configuration
How to fix "error: invalid configuration" in Kubernetes
etcdserver: cluster ID mismatch
How to fix "etcdserver: cluster ID mismatch" in Kubernetes
running with swap on is not supported
How to fix "running with swap on is not supported" in kubeadm