Spegel itself does not manage state as a normal registry would. Maybe ephemeral would be a better word to describe it. A normal registry would require some stateful storage solution along with a database to store image that clients push to it. Spegel exploits the fact that images used by containers will be stored on disk by Containerd for its benefit. Any image currently being used by a pod in a cluster will be available for all other nodes in the cluster to pull.
I am having some discussions about getting things working on GKE but I can't give an ETA as it really depends on how things align with deployment schedules. I am positive however that this will soon be resolved.
It's been a while since I looked at kuik, but I would say the main difference is that Spegel doesn't do any of the pulling or storage of images. Instead it relies on Containerd to do it for you. This also means that Spegel does not have to manage garbage collection. The nice thing with this is that it doesn't change how images are initially pulled from upstream and is able to serve images that exist on the node before Spegel runs.
Also it looks kuik uses CRDs to store information about where images are cached, while Spegel uses its own p2p solution to do the routing of traffic between nodes.
If you are running k3s in your homelab you can enable Spegel with a flag as it is an embedded feature.
Spegel does not only mirror Docker Hub, and works a lot differently than the alternatives you suggested. Instead of being yet another failure point closer to your production environment, it runs a distributed stateless registry inside of your Kubernetes cluster. By piggy backing off of Containerds image store it will distribute already pulled images inside of the cluster.
I initially built Spegel to deal with a series of GHCR outages along with rate limit changes in Docker Hub. I am a bit biased but it is a no brainier to run Spegel to mitigate these types of issues.
I am not to familiar with Kamal but it seems possible to integrate it with my project Spegel to remove some of the load from upstream. Especially if they are running clusters of servers physically located close to each other they could avoid some of the replication complexity with multiple Harbor instances.
Well your license is only as good as you are able to enforce it. Even with the law there is no guarantees.
I grew up thinking that people would follow the spirit of open source rather than the specific letter of the law. This is obviously not true, and probably never has been.
Any copies of the code should include the notice according to the MIT license. I do agree that I could have used a less permissive license, and it is something that I am now considering to change.
The reality is that licenses do not mean anything unless you are actually able to enforce it. So I really do not think the license would have mattered in this case.
I agree, after this happened to me I learned of a few other situations where the same thing happened to other friends.
On my end if was a mix of naivete and flattery which made me want to take the meeting. I suspect it is the same case for others. I will not make the same mistake the next time it happens.
Interesting idea to use the file path layout as a way to control the endpoints.
I do wonder though how you would deal with the Docker-Content-Digest header. While not required it is suggested that responses should include it as many clients expect it and will reject layers without the header.
Another thing to consider is that you will miss out on some feature from the OCI 1.1 spec like the referrers API as that would be a bit tricky to implement.
Kraken is sadly a dead project, with little work being done. For example support for Containerd is non-existent or just not documented.
I created Spegel to fill the gap but focus on the P2P registry component without the overhead of running a stateful application.
https://github.com/spegel-org/spegel
Some self promotion but I have built a project that aims to solve some of these issues in Kubernetes.
https://github.com/xenitAB/spegel
I have avoided a couple of incidents caused by images being removed or momentarily not reachable with it. It would at least mitigate any immediate issues caused by images being removed from Docker Hub.