Kubernetes couldn’t pull the container image because the image registry rejected the request due to an invalid tag.
Here’s why this happens and how to fix it:
Common Causes and Fixes
1. Typo in the Image Tag
- Diagnosis: Check your Deployment, Pod, or other workload YAML for the
image:field. Look for misspellings in the tag part. For example,myapp:latesttinstead ofmyapp:latest. - Fix: Correct the typo in your YAML. If the image is
myrepo/myapp:v1.2.3, ensure it’s written exactly like that.spec: containers: - name: myapp-container image: myrepo/myapp:v1.2.3 # Corrected tag - Why it works: Kubernetes uses the exact tag provided to request the image from the registry. A typo means it’s asking for a non-existent tag.
2. Using latest When It Doesn’t Exist
- Diagnosis: If your
image:field ismyrepo/myapp:latestand you’re getting this error, it’s highly probable that no image with thelatesttag has been pushed to the registry for that repository. - Fix: Push an image with the
latesttag or, more robustly, specify a specific, immutable tag (e.g.,v1.2.3,abc123def).# Example of pushing with a specific tag docker tag myapp:local_build myrepo/myapp:v1.0.0 docker push myrepo/myapp:v1.0.0 # Then update your YAML spec: containers: - name: myapp-container image: myrepo/myapp:v1.0.0 - Why it works: The
latesttag is a convention, not a guarantee. If no image has been explicitly tagged aslatest, the registry won’t have anything to serve. Using specific tags ensures you’re always referencing a known, existing image.
3. Image Tag Case Sensitivity
- Diagnosis: While image names are generally case-insensitive in Docker Hub and many other registries, tags can be case-sensitive depending on the registry implementation. Double-check the casing of your tag.
- Fix: Ensure the tag casing in your Kubernetes manifest exactly matches the casing in the registry. If the registry shows
v1.2.3, usev1.2.3, notV1.2.3.spec: containers: - name: myapp-container image: myrepo/myapp:v1.2.3 # Correct casing - Why it works: If the registry treats tags as case-sensitive, a mismatch will lead to the tag not being found.
4. Private Registry Authentication Issues (Incorrectly Applied)
- Diagnosis: If you’re using a private registry and the
imagePullSecretsare configured but the tag itself is somehow invalid or doesn’t exist in the registry even with authentication, you’ll still getErrImageNeverPull. The error message might be misleading here if you suspect auth is the only problem. Verify the tag exists in the registry manually usingdocker pull myrepo/myapp:the_tag_you_expect. - Fix: Ensure the image tag actually exists in the private registry. If it doesn’t, push the correct image with the correct tag. If the tag does exist but you’re still having issues, then investigate
imagePullSecretsmore deeply (e.g., incorrectserveraddress, expired credentials in the secret).# Example of a valid imagePullSecret referencing a private registry apiVersion: v1 kind: Secret metadata: name: my-registry-secret type: kubernetes.io/dockerconfigjson data: .dockerconfigjson: <base64-encoded-docker-config> # Contains auth for your registry# In your Deployment spec: containers: - name: myapp-container image: myprivateregistry.com/myapp:v1.0.0 imagePullSecrets: - name: my-registry-secret - Why it works: Even with proper authentication, Kubernetes can only pull an image that actually exists. This check confirms the image and tag are present before authentication is even fully leveraged to fetch the image manifest.
5. Image Repository Name Typo
- Diagnosis: While the error specifically mentions the tag, a typo in the repository or image name itself can sometimes manifest in confusing ways, especially if the typo results in a valid-looking but non-existent image path. For example,
myrepo/myapps:v1.0.0instead ofmyrepo/myapp:v1.0.0. - Fix: Carefully review the entire image string in your YAML, including the registry host (if specified), repository name, and image name, for any typos.
spec: containers: - name: myapp-container image: myrepo/myapp:v1.0.0 # Correct repository and image name - Why it works: The image reference must be perfectly accurate for the registry to locate the specified repository and image.
6. Registry Offline or Unreachable
- Diagnosis: While less common for
ErrImageNeverPull(which usually implies the registry responded but rejected the tag), a transient network issue or registry downtime during the initial lookup of the tag could theoretically cause this. Check network connectivity from your Kubernetes nodes to the image registry. - Fix: Ensure your Kubernetes nodes can reach the image registry over the network (e.g.,
curl https://myregistry.com/v2/myrepo/myapp/tags/list). Resolve any network or firewall issues.# Run this command from a node in your cluster to test connectivity curl -v https://myregistry.com/v2/myrepo/myapp/tags/list - Why it works: Kubernetes nodes need uninterrupted network access to the image registry to download container images.
The next error you’ll likely encounter if you fix the image tag and push issues is a CrashLoopBackOff if your application code itself has bugs.