Three years ago, I was part of a team responsible for developing and maintaining Kubernetes clusters for end user customers. A main source for downtime in customer environments occurred when image registries went down. The traditional way to solve this problem is to set up a stateful mirror, however we had to work within customer budget and time constraints which did not allow it. During a Black Friday, we started getting hit with a ton of traffic while GitHub container registries were down. This limited our ability to scale up the cluster as we depended on critical images from that registry. After this incident, I started thinking about a better way to avoid these scalability issues. A solution that did not need a stateful component and required minimal operational oversight. This is where the idea for Spegel came from.

As a sole maintainer of an open source project, I was enthused when Microsoft reached out to set up a meeting to talk about Spegel. The meeting went well, and I felt there was going to be a path forward ripe with cooperation and hopefully a place where I could onboard new maintainers. I continued discussions with one of the Microsoft engineers, helping them get Spegel running and answering any architecture questions they had. At the time I was positive as I saw it as a possibility for Micorosft to contribute back changes based on their learnings. As time went on, silence ensued, and I assumed work priorities had changed.

It was not until KubeCon Paris where I attended a talk that piqued my interest. The talk was about strategies to speed up image distribution where one strategy discussed