I’m running Docker Desktop with built-in / bundled Kuberentes in WSL. Every time a POD pulling a container image, the call to docker . io/library/< image:tag > fails for ImagePullErr . These images are standard ubuntu:latest or alpine: from any public registry lets say.
I workaround this failure by pulling the image locally. Subsequently i redeploy or rollout restart the pod in K8S. POD successfully creates the container.
What is happening behind the scenes? is docker dot io always meant to resolve to my local docker? how do i make the PODs in K8S (running inside the docker containers) to pull the images from public registry.
I have tried the same with KIND cluster running on top of my local docker. same behavior for container pull .
Ideally i wanted the K8S POD to pull automatically from the global public registry wherever the image exists eg. ubuntu:latest or busybox:latest rather than me locally pulling the image in my docker desktop
If you are trying official public images , Kubernetes should be able to pull. When you say you tried with “kind”, do you mean you enabled “kind” in Docker Desktop for Kubernetes?
What is your Docker Desktop version and what is the exact error message in addition to “imagePullErr”?
I know that Docker Desktop could have issues with tokens and sometimes logging out is required to update the tokens even for public images, but I don’t remember cases when docker pull worked but pulling images in Kubernetes didn’t..
Docker Desktop 4.43.2
Engine 28.3.2
Kubernetes 1.32.2 ( inbuilt kubernetes with KIND nodes instead of kubeadm)
Below is applicable to any image
command >
kubectl run -it --rm tester --image=alpine:latest --restart=Never – sh
POD failure from events log (adjusted spaces in url for readability…) > Failed to pull image “alpine:latest”: failed to pull and unpack image “docker . io/library/alpine : latest”: failed to read expected number of bytes: unexpected EOF’
Image TAG doesnt matter. same behavior with specifying an explicit tag as well.
My Q : why cant Kubernetes go beyond the local docker and hit the docker public registry (or whichever public registry providing that image) like when we docker run --rm alpine:latest
My workaround: i have to pull the images outside of kubernetes and stage it in my docker (seen in docker desktop as well). Its a pain to keep doing this prep work for kubernetes
the containers spun up as nodes for kubernetes (spun by Docker Desktop) run containerd process
the images pulled are stored in containerd registry on these nodes. verified by ctr and crictl commands.
I was able to see the logs for kubelet and containerd showing ImagePullErr when a pod deployment requesting the image pull .
from the K8S node (container itself spun by Docker desktop) i manually ran “ctr --namespace k8s .io image pull docker .io/library/alpine:latest” (extra spaces for readability here) … and it did pull the image from public docker hub registry
so im not sure why K8S Pod requesting the same container would fail.
Just use code blocks please, as described in our formatting guide and as you would on GitHub or any markdow-based editor. Then your commands and error messages can be copied as well easily to reproduce issues or search for errors: How to format your forum posts
Yes, this is how Kind works (Kubernetes in Docker)
I’m not sure either. Maybe the problem is accessing the containerd api if anything was corrupted in your Docker Desktop.
If you want to understand the networking of Docker Desktop, you can read this blog post which is old, but it should be something similar today.
What I can say is what I said before. Kubernetes should have no problem with pulling the image. I tried to reproduce the issue on my Mac. I trid the kubeadm-based and kind-based Kubernetes and both worked.
In general, proxy settings or VPN affected the network in Docker Desktop before, but I would expect it to fail with ctr too..
What is your host operating system and version? Cany ou show the docker info output? You can remove any private IP or username that you wouldn’t share before posting. And please, use code blocks.
I’m on Windows WSL2. May be its containerd but those are baked / brought in by KIND cluster spun by Docker Desktop. Individually tested the containerd image pull with
Sorry for the slow response. Your outputs look correct. I don’t know why it happened to you and not to me. And indeed, if ctr worked, I don’t see why Kubernetes could not pull images unless it is not a network issue but something between Kubernetes and containerd.
Maybe you could share the issue on GitHub if you haven’t done it yet
So someone at Docker with deeper knowledge about the Docker Desktop internals can try to reproduce it.
But in meantime, i uncovered / understood few other things .
in Each of the Containerd running on the nodes, there’s a config.toml file. I noticed an entry with registry.mirror:1273
after KIND create cluster, there’s a container kind-registry-mirror ( image: docker/desktop-containerd-registry-mirror:v0.0.2) . this container resolves to following DNS
So its evident that docker desktop or KIND is doing a registry mirror. That explains why docker image pull ( outside the kubernetes cluster) resolves the image pull in a pod.
I have the same problem to pull alpine image when I use kind cluster version 1.32.5 with 2 nodes (I didn’t try an other version). I don’t have any problen with kubeadm