Possible rate limits for pulling images from ghcr.io?

[prashant-warrier-echelonvi]

Select Topic Area

Question

Body

We host our packages in the form of docker container images on ghcr.io. These docker images are used to deploy various kinds of applications to multiple kubernetes clusters.

Each repository holds one docker image, and applications from that repository are deployed into a kubernetes namespace with the same name as that of the repository. All applications within that namespace use the same docker container image.

All the applications in that given namespace (whether it is a deployment, or a statefulset, or a cronjob) rely have .spec.imagePullSecrets configured to point to a secret that contains a github username and a PAT associated with that username. We know those credentials work because executing docker login using those credentials and then executing a docker pull ghcr.io/<org>/repo:<tag> works successfully.

However, on using the same credentials within a kubernetes cluster, pods get stuck in the ImagePullBackoff state, with kubectl describe pod ... indicating an HTTP 4xx status code for docker pulls.

This begs the question - does ghcr.io impose rate limits for pulling images from ghcr.io for a given username:PAT combination?

[benjimin]

Similar mentioned at #45253

[benjimin]

The overall docs appear to be here:
https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-container-registry
Note GHCR is branded as a component of GitHub Packages.

There appears to be no usage rate limit for public registries (although it is unclear if there are intentions for this to change).
https://docs.github.com/en/packages/learn-github-packages/introduction-to-github-packages#about-billing-for-github-packages

Otherwise, usage appears to be billed both by storage time and data transfer:
https://docs.github.com/en/billing/managing-billing-for-github-packages/about-billing-for-github-packages

[grandmas-favorite]

Nice @benjimin!

Thanks for helping out @prashant-warrier-echelonvi, I would have suggested the same resources!