For the past few months, Docker has been announcing the implementation of new pull rate limits for the Docker Hub. The most significant change is the 10 pulls-per-hour limit, per IP address, for unauthenticated users that can quickly lead to a “You have reached your pull rate limit” error message.

Even if these changes have been implemented and rollbacked as of April 1, 2025, at OVHcloud, we are aware that these upcoming changes could impact your deployments and daily work.

In this blog post, you will find several solutions and best practices that can help you reduce Docker pull commands and avoid hitting Docker Hub’s pull rate limit.

Use OVHcloud Managed Private Registry and activate the proxy cache

OVHcloud Managed Private Registry (MPR) is a container image registry, based on CNCF project Harbor. It allows you to store and manage Docker (or OCI-compliant) container images and artifacts in a private, secure, and scalable environment, hosted in OVHcloud’s infrastructure.

MPR provides a proxy cache feature that helps you mirror and cache images from external registries, like Docker Hub, Github Container Registry, Quay, JFrog Artifactory Registry, etc. External registries can be private or public. This improves performance and reduces rate limits imposed by external registries 💪.

Configure proxy cache in OVHcloud Managed Private Registry

If you don’t have deployed a MPR yet, you can deploy it through the OVHcloud Control Panel, the OVHcloud Terraform provider, the OVHcloud Pulumi provider and even the API. Follow the guide according to your needs.

First, log in the Harbor user interface on your private registry, follow the guide if you needed to.

⚠️ In order to activate the proxy cache, you need to log in the Harbor UI with an administrator account.

Registry endpoint creation

In the left sidebar, click on Registries (inside the Administration section).

Then click on the New endpoint button.

Select Docker Hub in the provider list, enter a name (“Docker Hub” for example), fill your Docker Hub login in Access ID field and fill your Docker Hub password in Access Secret field.

⚠️ Note that we strongly recommend using a Docker account (even a free one) to avoid rate limits, for unanthenticated users, when pulling images. Without authentication, Docker Hub enforces strict pull limits, which may cause failures when pulling frequently used images.

Click on the Test connection button to test if your login and password are correct.

Now click on the OK button in order to create the new endpoint.

The Docker Hub endpoint is created 🎉

Proxy cache project creation

In the left sidebar, click on Projects, then click on the New project button.

Enter a project name (“docker-hub” for example), enable the Proxy Cache, click on the Docker Hub endpoint in the list and click on the OK button.

ℹ️ Note that a project is private by default, so you have to click on the Public checkbox if you want to change the visibilty of a project.

⚠️ The name of a proxy cache project should not contains dot(s), indeed it can causes issues with external tools like Kaniko.

Your proxy cache project have been created 🎉

⚠️ A proxy cache project works similarly to a normal Harbor project, except that you are not able to push images to a proxy cache project.

Now when you want to pull a Docker images hosted in the Docker Hub you proxy cached, instead of pulling directly from the Docker Hub, you need to configure your docker/podman pull commands and Kubernetes pod manifests to pull images from the OVHcloud Managed Private Registry:

$ docker pull xxxxxxxx.c1.de1.container-registry.ovh.net/docker-hub/ovhcom/ovh-platform-hello:latest
latest: Pulling from docker-hub/ovhcom/ovh-platform-hello
1f3e46996e29: Pull complete 
6aa905c35cc0: Pull complete 
Digest: sha256:fddb76f0eb92d95b3721bfa0ea87350c5d39ea262e90cd30d66f429bb40c8b07
Status: Downloaded newer image for xxxxxxxx.c1.de1.container-registry.ovh.net/docker-hub/ovhcom/ovh-platform-hello:latest
xxxxxxxx.c1.de1.container-registry.ovh.net/docker-hub/ovhcom/ovh-platform-hello:latest

Disable the AlwaysPullImages admission plugin on your MKS cluster

By default, the AlwaysPullImages Kubernetes admission plugin is enabled in your OVHcloud Managed Kubernetes (MKS) cluster.

⚠️ When it is enabled, this forces the imagePullPolicy of a container to be set to Always, no matter how it is specified when creating the resource.

This is useful in a multitenant cluster so that users can be assured that their private images can only be used by those who have the credentials to pull them. Without this admission controller, once an image has been pulled to a node, any pod from any user can use it by knowing the image’s name (assuming the Pod is scheduled onto the right node), without any authorization check against the image.

But, it can cause a lot of pull requests to the Docker Hub and you can reach the rate limits.

So a solution can be to deactivate the AlwaysPullImages admission plugin in your MKS cluster.

In this blog post, we will deactivate it in the OVHcloud Control Panel.

Enable/Disable MKS admission plugins

Log in the OVHcloud Control Panel. In the left sidebar, click on the Managed Kubernetes Service and then click on the wanted MKS cluster.

In the Cluster information section, scroll down and click on Enable/disable plugin. A popup will appear.

Then click on Disable for the Always Pull Images plugin and click on the Save button.

⚠️ Any changes on the Admission plugins require a redeployment of the MKS cluster API server (without data loss) so the API server can be potentially not available during the redeployment.

Conclusion

To learn more about how to use and configure OVHcloud private registries and OVHcloud MKS clusters, don’t hesitate to follow our guides.

A couple of months ago, one year after the general availability of our Managed Kubernetes Service, we launched Managed Private Registry service. We shared in a previous blog post why we chose to base it on the CNCF Harbor project . Two OVHcloud employees became project maintainers. We now have a new event to celebrate: the Cloud-Native Computing Foundation just announced that Harbor joined the very restricted list of “Graduated” projects.

CNCF Graduation : The Ultimate Maturity Level

The CNCF hosts a few dozen open-source projects and does an excellent job offering those projects support for growth, both in terms of infrastructure and tools, but also community and awareness. However most of these projects are living in “the CNCF Sandbox” or the “Incubating” stage. There are currently only 11 projects that have “graduated”, including Kubernetes, Prometheus and Helm. Harbor is now the latest one to receive this great badge of recognition.

Each level reflects the completion of very specific maturity characteristics, enforced and validated by the CNCF Technical Oversight Committee. To graduate, Harbor for example has demonstrated that it has active committers from multiple organizations. It went through exhaustive and independent security audits and has fully transparent governance. Harbor also received a CII best practices badge.

OVHcloud Proudly Democratizing Harbor

Many enterprise-grade organizations already adopted Harbor as a part of commercial containerization platforms. They usually deploy and operate it on premise or in the cloud. If skeptics wanted a last sign to adopt Harbor, it has come… and OVHcloud is very proud to help make Harbor even simpler!

With our totally managed service, any OVHcloud user can benefit from a dedicated, highly available and full-featured Harbor. We offer totally predictable costs and enterprise-grade features that many cloud registries on the market lack. Those not yet ready to embrace the cloud will also benefit from our donation of what became the official Harbor Kubernetes operator to facilitate self-deployment and lifecycle in specific environments.

More for our current and future managed registry users!

Because we want you to celebrate with us, we are announcing today even more generous plans for our Managed Private Registry:

• the “M” plan, ideal for medium-sized software companies or business units in large organizations; now includes vulnerability scanning
• the “L” plan can now host up to 5 TB of your artifacts (container layers, Helm charts, etc.)

Prices and other characteristics are unchanged, making the service one of the most interesting enterprise-grade registry services on the market. All existing and future customers automatically benefit from these improvements. The public pricing page will be updated soon. Of course, as with most OVHcloud products, the ingress and egress traffic remain unlimited and at no charge.

Currently exposing the very stable Harbor 1.10, our container team already has plans to move to Harbor 2.0.

See you at the Kubecon Europe and OVHcloud summit later this year!

The need for a S.M.A.R.T private registry

After our Managed Kubernetes Service release, we received many requests  for a fully managed private container registry.

Though a container registry for hosting images may sound quite trivial to deploy, our users mentioned a production-grade registry solution was a critical part of the software delivery supply chain and was actually quite difficult to maintain.

Our customers were asking for an enterprise-grade solution, offering advanced role-based-access-control and security by design, as concerns around vulnerabilities within the publicly available images increased and requirements for content-trust became a necessity.

Users were regularly praising the user interface of services such as the Docker Hub, but at the same time requested a service with high availability and backed by SLA.

The perfect mix of open source and enterprise-grade feature set

After surveying prospects to fine tune our feature set and pricing model, we searched for the best existing technologies to back it and landed on the CNCF incubating project Harbor (donated to the CNCF by VMWare). In addition to Harbor being one of the few projects to reach CNCF incubation state, thus confirming the strong commitment from the community, it has as well become a key part of several commercial enterprise containerization solutions. We also appreciated the approach taken by Harbor of not re-inventing the wheel but gluing best-of-breed technologies for components such as vulnerability scanning, content trust and many others. It leverages CNCF’s strong network of open source projects and ensures great UX quality levels.

It was now the time to take this 10k-GitHub-stars technology and adapt it to our specific case : managing tens of thousands of registries for our users, each of them having specific volume of container images and usage patterns.

Of course high-availability (customers’s software integration and deployment rely on this service) but also data durability were non-negotiable for us.

In addition, Kubernetes to ensure stateless services HA and object storage (based on Openstack Swift and compatible with the S3 API) were evident choices to check those requirements.

Addressing  operational challenges at the cloud-provider scale

Within a few weeks, we opened the service in public beta, quickly attracting hundreds of active users. But with this surge in traffic, we naturally hit our first bottlenecks and performance challenges.

We approached the Harbor user group and team who kindly pointed us to potential solutions, and after some small but key changes to how Harbor handles database connections our issues were resolved. This reinforced our beliefs that the Harbor community is strong and committed to the health of the project and the requirements of its users.

As our service flourished there was no real tooling available to easily accommodate the life-cycle of Harbor instances. Our commitment to the Kubernetes ecosystem made the concept of a Harbor operator for Kubernetes an interesting approach.

We discussed with the Harbor maintainers and they warmly welcomed our idea to develop it, and open source it as the official Harbor Kubernetes Operator. OVHcloud is very proud to have the project now available in the goharbor GitHub project under Apache 2 licensing. This project is another example of our strong commitment towards open source and our willingness to contribute our efforts back to the projects that we love.

A versatile operator designed to accommodate any Harbor deployment

Readers familiar with the Harbor project may wonder what value this operator brings to the current catalogue of deployments including the Helm Chart version maintained by the project.

The operator design pattern is quickly catching on and mimics an application-centric controller that extends Kubernetes to manage more complex, stateful apps.  Simply put, It addresses different use-cases than those of Helm. Whereas the Helm chart offers an all-in-one installer that would also deploy the different dependencies of Harbor (database, cache, etc) from open source Docker images,other enterprises, service operators and cloud providers like us will want to pick-and-choose the service or technology behind those components.

We also aim at extending the current v0.5  operator to manage the full life-cycle of Harbor, from deployment to deletion, including scaling, updates, upgrades, and backup management.

This will help production users reach their target SLO, benefit from managed solutions or from existing databases clusters they already maintain for example.

We designed the operator (leveraging the OperatorSDK framework) so that both Harbor optional modules (Helm Chart store, vulnerability scanner etc) and dependencies (registry storage backend, relation and non relational databases, etc) can easily match your specific use case.

Contributing to Harbor and the operator project

We already have a roadmap planned with the Harbor maintainers to further enrich the operator to accommodate more than the deployment and destruction phases (for example making Harbor version upgrades more elegant). We look forward to being an integral part of the project and will continue investing in Harbor.

To that end, Jérémie Monsinjon and Pierre Peronnet have also been invited to be  maintainers of the Harbor project focusing on goharbor/operator .

In addition to regular contributions to multiple projects we use within OVHcloud, the container-platform team is also working on other major open sources releases, like an official OVHcloud cloud controller for self-managed Kubernetes we plan to deliver in late 2020.

Download Harbor or the Harbor Operator : Official Harbor Github repo

Learn more about Harbor : Official Harbor website