registry.k8s.io VS kraken

If you stop to think about, what AWS is selling here, it's quite funny. Most of the infrastructure behind registry.k8s.io is hosted on AWS (and also GCP). So AWS essentially tells you: Don't trust the upstream registry, it might go down, cache it on your own registry, hosted also by us.

For example: if you only allow cluster autoscaler and metrics server from registry.k8s.io you can pull those images through the cache as someone who has create repo IAM privileges. If someone without create repo privileges tries to pull a new image it will fail because they can't create the initial repo.

https://registry.k8s.io (the root url at /) redirects you to https://github.com/kubernetes/registry.k8s.io where we have an issue tracker.

❗ This container is having trouble accessing https://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.

Apart from reliability - GitHub's container registry is the current next best option - but we have to ask ourselves, what happens when they start charging or the outages start to last longer or are more frequent than 1-2 times per week as we've seen in Q1 2023.

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.

If you are using updated helm charts then most of them have already replaced with registry.k8s.io, for example nginx ingress so not really breaking change.

https://github.com/uber/kraken?tab=readme-ov-file#comparison...

"Kraken was initially built with a BitTorrent driver, however, we ended up implementing our P2P driver based on BitTorrent protocol to allow for tighter integration with storage solutions and more control over performance optimizations.

Kraken's problem space is slightly different than what BitTorrent was designed for. Kraken's goal is to reduce global max download time and communication overhead in a stable environment, while BitTorrent was designed for an unpredictable and adversarial environment, so it needs to preserve more copies of scarce data and defend against malicious or bad behaving peers.

Despite the differences, we re-examine Kraken's protocol from time to time, and if it's feasible, we hope to make it compatible with BitTorrent again."

Kraken seems unmaintained: https://github.com/uber/kraken/issues/313

For within your boundary of control, whether that be r/selfhosting, r/homelab, or enterprise a small registry or something like uber's kraken registry makes more sense.

First hit on Google is https://github.com/uber/kraken Did not know such thing exists.

Uber Engineering open-sourced Kraken [1], their peer-to-peer docker registry. I remember it originally using the BitTorrent protocol but in their readme they now say it is "based on BitTorrent" due to different tradeoffs they needed to make.

As far as I know there aren't any projects doing peer-to-peer distribution of container images to servers, probably because it's useful to be able to use a stock docker daemon on your server. The Kraken page references Dragonfly [2] but I haven't grokked it yet, it might be that.

It's also possible that in practice you'd want your CI nodes optimized for compute because they're doing a lot of work, your registry hosts for bandwidth, and your servers again for compute, and having one daemon to rule them all seems elegant but is actually overgeneralized, and specialization is better.

1 https://github.com/uber/kraken

If you're pulling big images you could try kube-fledged (it's the simplest option, a CRD that works like a pre-puller for your images), or if you have a big cluster you can try a p2p distributor, like kraken or dragonfly2.

Also there's that project called Nydus that allows starting up big containers way faster. IIRC, starts the container before pulling the whole image, and begins to pull data as needed from the registry.

https://github.com/senthilrch/kube-fledged

https://github.com/dragonflyoss/Dragonfly2

https://github.com/uber/kraken

https://nydus.dev/

Uber Kraken: Kraken is a P2P Docker registry capable of distributing TBs of data in seconds (URL: https://github.com/uber/kraken)

Might want to consider a private p2p solution like https://github.com/uber/kraken or similar.

Cost, availability, upkeep. Same as any other service. There are alternatives… https://github.com/uber/kraken