Unofficial list of FQDNs or ability to download as tar archive?
donaldm opened this issue · comments
Is there an existing issue for this?
- I have searched the existing issues
What did you expect to happen?
I was previously proxying k8s.gcr.io with Artifactory which worked fine in my restricted environment.
With the new registry.k8s.io the recommended solution is mirroring which is not feasible because I would need to have the FQDNs allowlisted in order to mirror them to my own local repository.
Debugging Information
n/a
Anything else?
Is there a paid service or some approach I can use to move forward here? I would be fine with downloading a tar archive and importing into my local repository if that was an option.
Thank you for any thoughts you can provide.
Code of Conduct
- I agree to follow this project's Code of Conduct
There is no list of FQDNs, this is covered by http://registry.k8s.io/#stability
With the new registry.k8s.io the recommended solution is mirroring which is not feasible because I would need to have the FQDNs allowlisted in order to mirror them to my own local repository.
You need to pull via a less restricted environment and then copy it to your registry or let through the current observed FQDNs long enough to populate the mirror. There is not a stable list of FQDNs though and there will not be (see #stability in the README).
Is there a paid service or some approach I can use to move forward here? I would be fine with downloading a tar archive and importing into my local repository if that was an option.
You can export images to an archive format using something like crane, but you will have to pick an environment that is not network restricted and run the export there. Any unrestricted network environment will do.
We don't maintain a list because the list is subject to change at any time anyhow in order to keep the registry sustainable and there does not appear to be any standard for maintaining and communicating such a list.
More importantly we don't want to setup a false expectation that there is a stable list or that we'll hesitate to leverage new hosts immediately when resources become available or we otherwise need to reconfigure the infrastructure. The team of contributors operating this infrastructure will leverage new hosts, regions, etc without notice to keep things affordable and maintainable.
You could identify the current set of FQDNs that apply to your traffic by observing what is blocked by your firewall and adding them or by inspecting the code and configs, but they're subject to change at any time.
An alternative would be using a Kubernetes distribution that provides and hosts images themselves, e.g. most large vendor provided offerings like EKS/AKS/GKE/Anthos/OpenShift/...
There are many artifactory instances currently spamming registry.k8s.io logs with attempts to pull content we don't even host 🙃 , I think typically they're configured to have less restricted network access.
Also #237
Thank you for the information. Unfortunately in my environment transferring via a less restrictive environment means sneaker netting a CD which is quite a time consuming process. I appreciate the feedback regardless and will try to come up with something on my end.
Is there a list of images somewhere that are hosted on the registry? It seems like that would make mirroring it easier. Also I don't know if you all have any plans to offer a paid service for people in similar situations? It seems like this issue is coming up a lot. Maybe an idea to help fund the project would be the ability to pay for a stable registry endpoint? just a thought
Is there a list of images somewhere that are hosted on the registry? It seems like that would make mirroring it easier.
The images are controlled by a yaml spec so you can find those in the registry.k8s.io directory in https://github.com/kubernetes/k8s.io repo however we have a LOT of images and you should really only mirror the images you plan to use. To determine that for popular tools see the mirroring guide linked from the README in this repo.
Also I don't know if you all have any plans to offer a paid service for people in similar situations? It seems like this issue is coming up a lot. Maybe an idea to help fund the project would be the ability to pay for a stable registry endpoint? just a thought
Kubernetes and the CNCF aren't really equipped for that but there are many vendors participating in the project that offer paid distributions that they host.