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:latestt instead of myapp: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 is myrepo/myapp:latest and you’re getting this error, it’s highly probable that no image with the latest tag has been pushed to the registry for that repository.
  • Fix: Push an image with the latest tag 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 latest tag is a convention, not a guarantee. If no image has been explicitly tagged as latest, 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, use v1.2.3, not V1.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 imagePullSecrets are configured but the tag itself is somehow invalid or doesn’t exist in the registry even with authentication, you’ll still get ErrImageNeverPull. The error message might be misleading here if you suspect auth is the only problem. Verify the tag exists in the registry manually using docker 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 imagePullSecrets more deeply (e.g., incorrect server address, 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.0 instead of myrepo/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.

Want structured learning?

Take the full Kubernetes course →