ErrImageNeverPull occurs when imagePullPolicy is set to Never but the required image does not exist locally on the node. Load the image into your cluster or change the pull policy.
ErrImageNeverPull indicates that a pod's container image is not available in the local container runtime, and the imagePullPolicy is set to Never, which prevents Kubernetes from attempting to pull it from a registry. This policy is commonly used in local development environments like Minikube or Kind where you want to use locally-built images. However, if the image isn't properly loaded into the cluster's container runtime or the image name doesn't match exactly, this error occurs.
Check what images are available in the cluster. For Minikube:
minikube ssh docker imagesFor Kind, exec into the control plane node:
docker exec -it kind-control-plane crictl imagesLook for your image with the exact name and tag specified in your pod spec.
If using Minikube, load your local image:
minikube image load myapp:latestOr build directly in Minikube's Docker environment:
eval $(minikube docker-env)
docker build -t myapp:latest .Note: Don't use sudo with docker commands after running eval—it breaks the environment.
For Kind clusters, use the kind load command:
kind load docker-image myapp:latestFor multi-node Kind clusters, load to specific nodes or all nodes:
kind load docker-image myapp:latest --nodes kind-worker,kind-worker2Verify it loaded: docker exec kind-control-plane crictl images | grep myapp
The image reference must match exactly. Common mismatches:
# If you built as 'myapp:v1', use exactly that
image: myapp:v1 # Correct
image: myapp # Wrong - defaults to :latest
image: docker.io/library/myapp:v1 # May not matchCheck your local image name:
docker images myappIf the strict Never policy isn't required, IfNotPresent is more flexible:
spec:
containers:
- name: myapp
image: myapp:v1
imagePullPolicy: IfNotPresentThis uses local images when available but falls back to pulling if missing. Better for development workflows where you might forget to load images.
In multi-node clusters, imagePullPolicy: Never requires the image on every node. A local registry is more practical:
# Run a local registry
docker run -d -p 5000:5000 --name registry registry:2
# Tag and push your image
docker tag myapp:latest localhost:5000/myapp:latest
docker push localhost:5000/myapp:latestThen use localhost:5000/myapp:latest in your pod spec with IfNotPresent.
For k3s clusters, use the fully qualified image path including docker.io/library/ prefix for Docker Hub images, as k3s uses containerd which handles image references differently.
In CI/CD pipelines with local clusters, ensure the image build step completes before the deploy step and that images are loaded into the cluster, not just the build agent's Docker daemon.
For production clusters, avoid imagePullPolicy: Never entirely. Push images to a proper container registry and use IfNotPresent or Always. The Never policy should only be used for local development and testing scenarios.
When using kaniko or buildah for in-cluster builds, images are typically pushed directly to a registry rather than loaded locally, making Never policy inappropriate.
No subnets found for EKS cluster
How to fix "eks subnet not found" in Kubernetes
unable to compute replica count
How to fix "unable to compute replica count" in Kubernetes HPA
error: context not found
How to fix "error: context not found" in Kubernetes
default backend - 404
How to fix "default backend - 404" in Kubernetes Ingress
serviceaccount cannot list resource
How to fix "serviceaccount cannot list resource" in Kubernetes