IBM Support

Managing Docker Hub Rate Limits for Kubernetes Deployments of IBM Sterling Containerized Services

How To


Summary

This technote offers a detailed guide on managing Docker Hub's rate limits when deploying IBM Sterling containerized services, such as Order Management (OMS) and Inteligent Promising (SIP), using Kubernetes. Discover practical strategies to improve efficiency and prevent service disruptions.

Objective

Managing Docker Hub Rate Limits in Modern Cloud Environments

In managing modern cloud environments, it is essential to effectively handle Docker Hub's rate limits to ensure seamless operations. This is particularly crucial when deploying services using Kubernetes Operators, where frequent image pulls are common. Whether you are setting up new environments or scaling existing applications, running into rate limits can cause significant delays.

Understanding Docker Hub Rate Limits

Docker Hub imposes rate limits on image pulls:

  • Anonymous Users: 100 pulls per 6 hours.
  • Authenticated Users: 200 pulls per 6 hours.

Detailed information can be found in Docker's Rate Limit Documentation.

This is particularly problematic in a busy setting where each environment setup could require multiple image pulls.

Strategies to Manage Docker Hub Rate Limits

In this guide, we will explore strategies to efficiently manage these rate limits using Docker, Podman, and Kubernetes Operators, aiming to streamline your workflows and enhance your deployment processes.

Note: The strategies outlined in this article are specifically for managing Docker Hub rate limits while installing external middleware services like Cassandra, Elasticsearch, DB2, etc. They are not applicable to product images that use our authenticated registry (cp.icr.io).

Steps

Strategies for Efficient Management

In this exploration, we will discuss two different scenarios crucial to managing and deploying services in the realm of Docker and Kubernetes. Each scenario caters to specific deployment needs and understanding these will enable you to tailor your strategies effectively.

  • Individual Docker Image Deployment: This scenario involves the direct pulling of specific Docker images, such as DB2. 
  • Deployment Using the Operator in 'createDevInstance' Mode: In this scenario, Kubernetes Operators are utilized to streamline the deployment of complex services like Cassandra, ES, and Kafka. This is especially relevant in integrated systems where automation simplifies deployment and mitigates issues such as rate limits on Docker Hub.

Scenario 1: Docker or Podman Image Pull

To navigate past these rate limit challenges, consider the following steps:

Docker Hub Authentication

Enhancing pull rate limits starts with Docker Hub authentication. Account creation is detailed on Docker Hub Sign Up.

Using Podman

sudo podman login docker.io

Using Docker

docker login

Executing Container Commands

With an enhanced pull limit, executing container commands becomes more streamlined. For instance, in Podman:

sudo podman run -itd --name mydb2 --privileged=true -p 50000:50000 -e LICENSE=accept -e DB2INST1_PASSWORD=db2inst1 -e DBNAME=omdb -v db2_database:/database ibmcom/db2

Scenario 2: Operator Deployment in Kubernetes

When deploying applications using Kubernetes Operators, especially in environments like 'createDevInstance' mode, we encounter a unique set of challenges linked to Docker Hub's rate limits. Operators, designed to automate and simplify the deployment of complex applications, often pull multiple images from Docker Hub, such as those needed for services like Cassandra, ES, and Kafka.

To prevent disruptions in automated deployments managed by Operators, consider the following steps. Deploying Operators in Kubernetes necessitates passing Docker credentials via a pull secret:

i. Create a Docker Registry Secret:

kubectl create secret docker-registry regcred --docker-server=<your-registry-server> --docker-username=<your-name> --docker-password=<your-pword> --docker-email=<your-email>

Use https://index.docker.io/v1/ for DockerHub.

kubectl create secret docker-registry regcred --docker-server='https://index.docker.io/v1/' --docker-username=c3a --docker-password=Dockercontainers2@ --docker-email=c3a@gmail.com

ii. Update Operator Deployment YAML:

In your Operator's deployment YAML, include the pull secret.

spec:
  image:
    pullPolicy: Always
    imagePullSecrets:
    - name: ibm-entitlement-key
    - name: regcred
    repository: registry.access.redhat.com

    ivService:
      appImageName: sip-iv-appserver
      backendImageName: sip-iv-backend
      onboardImageName: sip-iv-onboard
      pullPolicy: IfNotPresent
      tag: 10.0.2403.0-amd64
      repository: cp.icr.io/cp/ibm-oms-enterprise

Effectively handling Docker Hub's rate limits is essential, especially when using Kubernetes Operators. By using tools like Docker and Podman, along with smart Kubernetes setups, we keep our workflow smooth and uninterrupted. 

Document Location

Worldwide

[{"Type":"MASTER","Line of Business":{"code":"LOB59","label":"Sustainability Software"},"Business Unit":{"code":"BU048","label":"IBM Software"},"Product":{"code":"SSGTJF","label":"IBM Sterling Order Management System"},"ARM Category":[{"code":"a8m0z000000cxzWAAQ","label":"Install and Deploy"}],"ARM Case Number":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"}]

Product Synonym

OMS;SIP;Intelligent Promising;Promising

Document Information

Modified date:
10 May 2024

UID

ibm17150858