Support request for exceeding Docker Hub rate limit for Prometheus and NATS

[AlexanderB1290]

Deploying OpenFaaS in K8S clusters with Helm chart fails with ErrImagePull and then the error is changed to ImagePullBackOff. In the logs of the crashed pods is observed the error: Docker pull rate limit reached.

Expected Behaviour

Adding a posibility to authenticate with K8S secrets for different image repositories - Google, Docker, private repositories, when deploying OpenFaaS using Helm charts.

Current Behaviour

If imagePullSecrets is not provided to be used for authentication during pods creation, the pods are failing with ErrImagePull (ImagePullBackOff). In the describe of the pods is monitored an error message for reaching Docker Hub pull rate limit.

Why is this needed?

Docker Hub has set a pull rate limit as follows:

• Anonymous users - 100 pulls per 6 hours
• Authenticated users - 200 pulls per 6 hours
• Paid users with subscription - 5000 pulls per day

Private repositories are set to require authentication by default and have limited permissions.

Adding the possibility to authenticate with Docker Hub, Google and private repositories elimitaes the limitation of pull rates and provides access to locked (and private) repositories.

Who is this for?

Everyone that have large scale K8S cluster with OpenFaaS and tries to deploy it multiple locations or needs HA with high scalability.

List All Possible Solutions and Workarounds

Workaround

1. Download locally the helm chart.
2. Edit the templates for each pod.
3. Add imagePullSecrets with the corresponding secrets used for authentication in the spec section.
4. Deploy the local helm chart

Solution

1. Add input value to the Helm chart that will contain all secrets used for authencation
2. Update the helm templates
3. If value for secrets is provided, add the secrets to the spec section under imagePullSecrets.
4. If value for secrets is not provided, don't add the section imagePullSecrets under the spec section of the template.

Steps to Reproduce (for bugs)

1. Reach the maximum pull rate limit with Anonymous Docker Hub account.
2. Deploy OpenFaaS in K8S cluster using Helm charts.

Context

Beening able to download and setup OpenFaaS to operate 24/7 and update regularly in large scale K8S cluster without reaching the pull rate limit of the Docker Hub, been able to download images from private repositories or repositories requiring explicit authentication.

Your Environment

• FaaS-CLI version:
  commit: b1c09c0243f69990b6c81a17d7337f0fd23e7542
  version: 0.14.2

• Docker version: 20.10.21 (1.41 API version)

• What version and distriubtion of Kubernetes are you using?: 1.24.13-2+cd9733de84ad4b

• Operating System and version (e.g. Linux, Windows, MacOS): Ubuntu 18.04.3 LTS

• Link to your project or a code example to reproduce issue: Private repository, can not provide access.

• What network driver are you using and what CIDR?: Private CIDR in virtual environment. Drivers for ethernet: 0b:00.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)

[alexellis]

Hi,

Thanks for the interest in the Community Edition of OpenFaaS.

You mention rate limits for the Docker Hub, however we do not publish images to the Docker Hub. No OpenFaaS CE or Pro image should be rate-limited, since they're hosted on GHCR.io.

That said, Prometheus and NATS (referenced in the chart) are both hosted on the Docker Hub, as we do not control them.

If you enable an image pull secret for the service account like we suggest doing for functions, you should be able to use your own authentication for the Docker Hub to install Prometheus and NATS.

See the heading: Option 1 - Link an image pull secret to the namespace's ServiceAccount](https://docs.openfaas.com/reference/private-registries/#option-1-link-an-image-pull-secret-to-the-namespaces-serviceaccount)

You can patch the default service account with kubectl or with a YAML file applied after deployment with Helm.

Alternatively, perhaps you could mirror NATS and Prometheus yourself into your own local registry mirror, with or without authentication. If you go for this option, simply edit your values.yaml file and set "nats.image=local-mirror/...." etc

Add imagePullSecrets with the corresponding secrets used for authentication in the spec section.

We'll monitor feedback from other users to decide whether this is something we should do or not. The two alternatives I've suggested should resolve any problem you're running into satisfactorily.

Alex