registry.k8s.io

Hosting a forwarding / redirect server instead of actually hosting images is probably a decent idea. The K8s proxy is redirecting from only hosting on GCR to community-owned registries - https://kubernetes.io/blog/2023/03/10/image-registry-redirec... You can view the code here - https://github.com/kubernetes/registry.k8s.io But because everyone is already pointing at gcr.io (just like many openfaas users point at docker.io/) - they're having to do a huge campaign to announce the new URL - the same would apply with the author's solution here. I wrote some automation for hosting (not redirects) in arkade with the OSS registry - Get a TLS-enabled Docker registry in 5 minutes - https://blog.alexellis.io/get-a-tls-enabled-docker-registry-... The registry is also something you can run on a VM if you so wish, and have act as a pull through cache

Thanks for the write up. I was planning to look into this on the weekend and now I don’t have to! A slightly fancier version of this concept is the Kubernetes official registry, registry.k8s.io . https://github.com/kubernetes/registry.k8s.io Their registry forwards to a container registry by default. But if it detects if the request is coming from inside AWS or Google Cloud, it forwards requests for blobs to a S3 or GCS bucket near the requester. This saves money on cloud egress charges.

One annoyance with how docker images are specified is they include the location where they are stored. So if you want to change where you store you image you break everyone. I wonder if what regsitry.k8s.io does could be generalized: https://github.com/kubernetes/registry.k8s.io/blob/main/cmd/... The idea is the depending on which cloud you are pulling the image from, they will use the closest blob store to service the request. This also has the effect that you could change the source of truth for the registry without breaking all Dockerfiles.