ErrImageNeverPull: The image is not present on the node and imagePullPolicy is Never

ErrImageNeverPull means the pod sets imagePullPolicy: Never, the image is not already on the node, and Kubernetes is respecting the instruction not to fetch it. Nothing is broken; the image simply is not there.

Applies to: All Kubernetes versions, any container runtime

What it means

imagePullPolicy: Never tells the kubelet to use only images already present in the node's local image store. If the image is absent, the kubelet does not attempt a pull — it reports ErrImageNeverPull and waits. This policy exists mainly for local development clusters where images are built or loaded directly onto the node, so the most common way to hit it is a local workflow where the image was built in a different image store than the one the cluster's runtime reads. Building with Docker while the cluster runs containerd, or building on the host while a kind or minikube node has its own store, produces exactly this.

Most common causes

• The image was built locally but never loaded into the cluster node's image store.
• The image was built into Docker's store while the node's runtime is containerd, which reads a different store.
• A multi-node local cluster where the image was loaded onto one node and the pod was scheduled onto another.
• The tag on the node differs from the tag in the pod spec, including the implicit :latest.
• imagePullPolicy: Never was copied from a development manifest into an environment where the image only exists in a registry.
• The node's image cache was garbage-collected under disk pressure, removing an image the pod relied on.

How to diagnose it

1. Confirm the policy is what you think: kubectl get pod POD -o jsonpath='{.spec.containers[*].imagePullPolicy}'.
2. List the images actually present on the node the pod landed on: crictl images on that node, or the loader command for your local cluster.
3. Compare the tag exactly. An image present as app:dev does not satisfy a spec asking for app:latest.
4. Check which node the pod is on: kubectl get pod POD -o wide. On a multi-node local cluster this is usually the answer.

How to fix it

1. Load the image into the cluster's own store — kind load docker-image, minikube image load, or building directly against the cluster's runtime.
2. On a multi-node local cluster, load the image onto every node, or pin the pod to the node that has it.
3. Change the policy to IfNotPresent and push the image to a registry the cluster can reach.
4. Use explicit, unique tags rather than :latest, so what is on the node and what is in the spec cannot drift silently.

Notes

An image with no tag defaults to :latest, and an image whose tag is :latest defaults to imagePullPolicy: Always unless you set it explicitly. Those two defaults interact in ways that make local development surprisingly easy to get wrong.

Related

• ErrImagePull — The pull was attempted and failed
• InvalidImageName — The image reference could not be parsed

Sources

• Kubernetes documentation — Images: image pull policy
• Kubernetes documentation — Debug Pods