Migrating our container images to GitHub Container Registry
KEDA Maintainers
March 26, 2021
We provide various ways to deploy KEDA in your cluster including by using Helm chart, Operator Hub and raw YAML specifications.
These deployment options all rely on the container images that we provide which are available on Docker Hub, the industry standard for public container images.
However, we have found that Docker Hub is no longer the best place for our container images and are migrating to GitHub Container Registry (Preview).
Why are making this change?
Docker Hub is introducing rate limiting and image retention
Over the past couple of years, Docker Hub has become the industry standard for hosting public container images. This has become a big burden for Docker to manage all the traffic and decided in 2020 to make some changes:
- Anonymous image pulls are being rate limited
- Unused images will no longer be retained
Because we want to ensure that our end-users can use KEDA without any issues, we want to make them available to anyone without any limitations.
Learn more about these changes in Docker’s FAQ and our issue on GitHub.
Gaining insights on KEDA adoption
As maintainers, we find it hard to measure the adoption of KEDA to understand how many end-users are using older versions of KEDA and what the growth is over time.
Docker Hub provides a vague total pull count per container image, but it does not give in-depth details concerning the tags and what the pull growth is over time.
In GitHub Container Registry, however, metrics are provided out-of-the-box on a per-tag basis allowing us to better understand what our customers are using and make better decisions when we no longer support a given version.
Bringing our artifacts closer to home
Lastly, we want to bring our artifacts closer to our home on GitHub. By using more of the GitHub ecosystem, we believe that this integration will only improve and get tighter integration with our releases and such.
What is changing?
Our container images are being published on GitHub Container Registry for end-users to pull them.
Because of this, the names of our container images are changing:
Component | New Image (GitHub Container Registry) | Legacy Image (Docker Hub) |
---|---|---|
Metrics Server | ghcr.io/kedacore/keda-metrics-apiserver | kedacore/keda-metrics-apiserver |
Operator | ghcr.io/kedacore/keda | kedacore/keda |
When is this taking place?
As of v2.2, we have started publishing our new container images to GitHub Container Registry in parallel to Docker Hub.
This allows customers to already migrate to our new registry and consume our artifacts there.
Once GitHub Container Registry becomes generally available (GA), we will no longer publish new versions to Docker Hub.
What is the impact for end-users?
If you are using one of our deployment options, end-users are not be impacted.
Since v2.2, we are using GitHub Container Registry by default and you are good to go.
If you are using your own deployment mechanism, then you will have to pull the container images from GitHub Container Registry instead.
Join the conversation
Do you have questions or remarks? Feel free to join the conversation on GitHub Discussions.
Thanks for reading, and happy scaling!
KEDA Maintainers.
Recent posts
KEDA is graduating to CNCF Graduated project 🎉Securing autoscaling with the newly improved certificate management in KEDA 2.10
Help shape the future of KEDA with our survey 📝
Announcing KEDA v2.9 🎉
HTTP add-on is looking for contributors by end of November
Announcing KEDA v2.8 🎉
How Zapier uses KEDA
Introducing PredictKube - an AI-based predictive autoscaler for KEDA made by Dysnix
How CAST AI uses KEDA for Kubernetes autoscaling
Announcing KEDA HTTP Add-on v0.1.0
Autoscaling Azure Pipelines agents with KEDA
Why Alibaba Cloud uses KEDA for application autoscaling
Migrating our container images to GitHub Container Registry
Announcing KEDA 2.0 - Taking app autoscaling to the next level
Give KEDA 2.0 (Beta) a test drive
Kubernetes Event-driven Autoscaling (KEDA) is now an official CNCF Sandbox project 🎉