-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Running an in-cluster image registry on localhost #602
Comments
Does it actually make it faster? Note that image loading in docker at least also skips layers that are already loaded. |
The biggest problem is docker for mac / windows, where the host won't have access to the node IPs so we'd need additional port forwarding for the registry. Otherwise, deploying a registry shouldn't be much different on kind than any Kubernetes host, there's just no built in add-ons. 🤔 |
re: making it faster: here are some numbers on my Linux machine with a warm registry (where i've already pushed the image once, and want to push it a second time) with KIND:
with MicroK8s:
so yes, this is 100x slower on KIND |
re: port-forwarding: yes! It might not be a lot of engineering work. An end-user can do a lot of this manually. I think the big pieces are:
It might be as simple as documentation on how to put the pieces together. I would be happy to try to contribute something like this but might need help. |
🤔 those layers already exist in the repository, is this a fair comparison? |
@aojea Yes, I'm interested in "warm" performance where the layers are already in the registry. The Let me know if this is just a misunderstanding, or if there's a reason why you think that's not fair |
Thanks for the data, that additional slowness is likely due to #382 not being in yet (so we're still doing an unnecessary |
1.) And 2.) Should be relatively standard. |
yes, #382 helps a lot!
slightly slower than using a registry, but i'll take the bird in the hand. |
hmmm...I think using a registry will still be a lot faster in the case where you have two different images that share most of their base layers, right? |
It might be a lot faster with lots of nodes or frequently reusing a layer but not the whole image purely because of the save side of the operation on the host, the load side is layer based internally and skips existing layers. |
A guide for doing this would be a nice addition to the docs. |
I put together a small proof of concept on how to do this: It's not super robust, but all the pieces are there. |
Thanks! looks like we'll need #110, soon we'll have port forwards to the host that could help get traffic to the registry from mac etc. |
#382 is now in as well 😅 |
#110 is progressing. |
https://kind.sigs.k8s.io/docs/user/local-registry/ not the most elegant, but it's a starting point. thinking about the UX of a friendlier option |
Yes, that's exactly what I wanted! I can work with that! Thanks!! This can be closed (unless you wanted to leave it open to talk about friendlier UX) |
also -- if there's anything we can do to help to make this friendlier, we'd be happy to contribute engineering/documentation work. I was thinking a UI more like
but would trust your judgment on the right thing here! |
#1213 makes for a broader issue, this one is older but more specific on one particular approach, going to dedupe for that one I suppose ... |
What would you like to be added:
A lot of local kubernetes solutions let you run an image registry in-cluster, and push images directly to that registry.
You port-forward the registry to localhost:32000, so that images tagged "localhost:32000" get pushed to the in-cluster registry. The cluster is configured to trust images from that registry.
This document from the MicroK8s team has a good summary of the feature under "Working with MicroK8s’ registry add-on"
https://microk8s.io/docs/working
Why is this needed:
This makes loading images into the cluster orders of magnitude faster. Even faster than side-loading with image import/export, because the registry protocol can skip layers that have already been pushed.
Even documentation on how to do this with KIND would help a lot!
The text was updated successfully, but these errors were encountered: