-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"minikube image ls" confusingly adds "docker.io/" prefix #19343
Comments
The implementation is buggy, but it needs to use long names for some of the runtimes to work properly. Kubernetes itself adds the prefix, so for instance containerd can't run images created by buildkitd It is not supposed to do anything weird, like replace qualified images with docker.io or somesuch |
Wow, thanks for the instant response! I stripped out the |
I think it could use some refactoring ( But the main idea was to provide a unified interface to all three container runtimes, for load and build. I am not aware that other pieces of minikube should use it, but the code is quite old so that could be... Upstream (k8s) uses this wrapper: https://github.com/distribution/reference/blob/main/normalize.go Qualifying the names is a feature:
Other discussions around it include: https://www.redhat.com/sysadmin/container-image-short-names https://www.redhat.com/en/blog/be-careful-when-pulling-images-short-name |
But if I inspect the pulled image, the long name is not represented in the RepoTags: $ docker image inspect busybox | jq -c '.[].RepoTags'
["busybox:latest"] Nor is it contained in the on-disk representation when you do My reading of the Red Hat articles is that short vs. long names are a "pushing and pulling" concern. When you're transferring images, you need a domain name to know where to send/receive them. But when the images are "at rest," stored in the local Docker/Podman storage, they are represented only by their repo tags. (Of course, all I really want is a way to reliably test if my image has been successfully loaded to the cluster via |
Yeah, unfortunately Kubernetes (and e.g. CRI) does not have a position on how to specify/qualify images. Anyway the feature was added since containerd is a bit more picky about image names than dockerd was. |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale There was some discussion over this recently |
What Happened?
When you load an image into Minikube, and then list the images using
minikube image ls
, it may sometimes adddocker.io/
ordocker.io/library/
as a prefix to your image.I was scratching my head over why this was happening, until I found this code:
https://github.com/kubernetes/minikube/blob/master/pkg/minikube/cruntime/docker.go#L699-L719
These prefixes are added based on a pretty arbitrary criterion -- whether the image name contains a dot or not. Apparently the idea is to force a leading domain name to be on an image, so as to turn
busybox:latest
intodocker.io/library/busybox:latest
.This behavior might have made sense when DockerHub was the only game in town, but I don't think Minikube should a) misrepresent the actual RepoTags coming from Docker or b) privilege the
docker.io
prefix in this way. After all, you can construct and load container images that have nothing to do withdocker.io
but will still get prefixed.When the reported RepoTags are different from the one in the image I loaded, it makes it difficult to verify that an image was loaded correctly. This is especially vexing when combined with the fact that
minikube image load
sometimes silently fails.If there's a good reason for this behavior please let me know. I just experimented with removing it and it seems to work fine. PR incoming.
Attach the log file
Operating System
Ubuntu
Driver
Docker
The text was updated successfully, but these errors were encountered: