{
  "id": "container-images",
  "title": "Use a private registry for container images",
  "url": "https://redis.io/docs/latest/operate/kubernetes/7.8.4/deployment/container-images/",
  "summary": "This section details how the Redis Enterprise Software and Kubernetes operator images can be configured to be pulled from a variety of sources. This page describes how to configure alternate private repositories for images, plus some techniques for handling public repositories with rate limiting.",
  "content": "\nRedis Enterprise Software, its Kubernetes operator, and the Service Rigger\nare all distributed as separate container images.\nYour Kubernetes deployment will pull these images as needed.\n You can control where these images are\npulled from within the operator deployment and also via the\nRedis Enterprise custom resources.\n\nIn general, images for deployments that do not have a registry domain\nname (e.g., `gcr.io` or `localhost:5000`) are pulled from the default registry associated\nwith the Kubernetes cluster. A plain reference to `redislabs/redis` will likely pull from DockerHub\n(except on OpenShift where it pulls from Red Hat).\n\nFor security reasons (e.g., in air-gapped environments), you may want to pull the images\nfrom a public registry once and then push them to a private registry under\nyour control.\n\nIt is very important that the images you are pushing to the private registry have the same exact version tag as the original images. \n\nFurthermore, because [Docker rate limits public pulls](https://www.docker.com/blog/scaling-docker-to-serve-millions-more-developers-network-egress/),\nyou may want to consider pulling images from a\nprivate registry to avoid deployment failures when you hit your DockerHub rate limit.\n\nThe information below will help you track and configure where your deployments pull container images.\n\n\n**IMPORTANT**\n* Each version of the Redis Enterprise operator is mapped to a specific version of Redis Enterprise Software. The semantic versions always match (for example, 7.2.4), although the specific release numbers may be different (for example, 7.2.4-7 is the operator version for Redis Enterprise Software 7.2.4-64).\n* A specific operator version only supports a specific Redis Enterprise version. Other combinations of operator and Redis Enterprise versions are **not supported**.\n\n\n\n## Find container sources\n\nEvery pod in your deployed application has a source registry. Any image not prefixed by a registry domain name (e.g., \"gcr.io\") will pull from the default registry for the Kubernetes cluster (i.e., DockerHub). You can use the commands below to discover the pull sources for the images on your cluster.\n\nTo list all the images used by your cluster:\n\n```sh\nkubectl get pods --all-namespaces -o jsonpath=\"{..image}\" |tr -s '[[:space:]]' '\\n' | uniq -c\n```\n\nTo specifically determine the pull source for the Redis Enterprise operator itself, run the following command:\n\n```sh\nkubectl get pods --all-namespaces -o jsonpath=\"{..image}\" |tr -s '[[:space:]]' '\\n' | uniq -c | grep redislabs\n```\n\nYou can limit this command to specific namespaces by replacing the `--all-namespaces` parameter with\na set of `-n {namespace}` parameters, where each `{namespace}` is a specific\nnamespace of interest on your cluster.\n\n## Create a private container registry\n\nYou can set up a private container registry in a couple of ways:\n\n* On-premise via [Docker registry](https://docs.docker.com/registry/deploying/), [Red Hat Quay](https://www.redhat.com/en/technologies/cloud-computing/quay), or other providers\n* Cloud provider based registries (e.g., Azure Container Registry, Google Container Registry, etc.).\n\nOnce you have set up a private container registry, you will identify the container registry using:\n\n* A domain name\n* A port (optional)\n* A repository path (optional)\n\n## Push images to a private container registry\n\nImportant images for a Redis Enterprise Software deployment include:\n\n* Redis Enterprise Software\n* Bootstrapping a Redis Enterprise cluster node (in the operator image)\n* The Service Rigger\n* The Redis Enterprise Software operator\n\nYou will need to push all these images to your private container registry. In general,\nto push the images you must:\n\n 1. [Pull](https://docs.docker.com/engine/reference/commandline/pull/) the various images locally for the Redis Enterprise Software, the Service Rigger, and the operator.\n 2. Tag the local images with the private container registry, repository, and version tag.\n 3. [Push](https://docs.docker.com/engine/reference/commandline/push/) the newly tagged images.\n\nThe example below shows the commands for pushing the images for Redis Enterprise Software and its operator to a private container registry:\n\n```sh\nPRIVATE_REPO=...your repo...\nRS_VERSION=7.2.4-64\nOPERATOR_VERSION=7.2.4-7\ndocker pull redislabs/redis:${RS_VERSION}\ndocker pull redislabs/operator:${OPERATOR_VERSION}\ndocker pull redislabs/k8s-controller:${OPERATOR_VERSION}\ndocker tag redislabs/redis:${RS_VERSION} ${PRIVATE_REPO}/redislabs/redis:${RS_VERSION}\ndocker tag redislabs/operator:${OPERATOR_VERSION} ${PRIVATE_REPO}/redislabs/operator:${OPERATOR_VERSION}\ndocker tag redislabs/k8s-controller:${OPERATOR_VERSION} ${PRIVATE_REPO}/redislabs/k8s-controller:${OPERATOR_VERSION}\ndocker push ${PRIVATE_REPO}/redislabs/redis:${RS_VERSION}\ndocker push ${PRIVATE_REPO}/redislabs/operator:${OPERATOR_VERSION}\ndocker push ${PRIVATE_REPO}/redislabs/k8s-controller:${OPERATOR_VERSION}\n```\n\n## Configure deployments to use a private container registry\n\nOnce you push your images to your private container registry, you need to\nconfigure your deployments to use that registry for Redis Enterprise Software and operator\ndeployments. The operator container image is configured directly by the operator deployment\nbundle. The Redis Enterprise cluster pod (RS and bootstrapper) and Service Rigger\nimages are configured in the Redis Enterprise custom resource.\n\nDepending on your Kubernetes platform, your private container registry may\nrequire authentication. If you do need authentication, add a [pull secret](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/) to your namespace. Then you'll need to configure Kubernetes and the operator to use the pull secret. The two following sections have examples of adding the `imagePullSecrets` to the operator deployment and `pullSecrets` to the cluster custom resource.\n\n### Specify the operator image source\n\nThe operator bundle contains the operator deployment and the reference to the operator image (`redislabs/operator`). To use a private container registry, you must\nchange this image reference in your operator deployment file **before** you deploy the operator. If you apply this change to modify an existing operator deployment, the operator's pod will restart.\n\nIn the operator deployment file, 'containers:image' should point to the same repository and tag you used when [pushing]() to the private container registry:\n\n```sh\n${PRIVATE_REPO}/redislabs/operator:${OPERATOR_VERSION}\n```\n\nThe example below specifies a 7.2.4-7 operator image in a Google Container Registry:\n\n```YAML\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: redis-enterprise-operator\nspec:\n  replicas: 1\n  selector:\n    matchLabels:\n      name: redis-enterprise-operator\n  template:\n    metadata:\n      labels:\n        name: redis-enterprise-operator\n    spec:\n      serviceAccountName: redis-enterprise-operator\n      containers:\n        - name: redis-enterprise-operator\n          image: gcr.io/yourproject/redislabs/operator:7.2.4-7\n...\n```\n\nIf your container registry requires a pull secret, configure `imagePullSecrets` on the operator deployment:\n\n```YAML\nspec:\n  template:\n    spec:\n      imagePullSecrets:\n      - name: regcred\n```\n\n### Specify the Redis Enterprise cluster images source\n\nA Redis Enterprise cluster managed by the operator consists of three\ncontainer images:\n\n* **`redislabs/redis`**: the Redis Enterprise Software container image\n* **`redislabs/operator`**: the bootstrapper is packaged within the operator container image\n* **`redislabs/k8s-controller`**: the Service Rigger container image\n\nBy default, a new Redis Enterprise cluster is created using the\ncontainer images listed above. These container images are pulled from the K8s cluster's default\ncontainer registry.\n\nTo [pull](https://docs.docker.com/engine/reference/commandline/pull/) the Redis Enterprise container images from\na private container registry, you must specify them in the\nRedis Enterprise cluster custom resource.\n\nAdd the following sections to the `spec` section of your RedisEnterpriseCluster resource file:\n\n * **`redisEnterpriseImageSpec`**: controls the Redis Enterprise Software container image. *The version should match the RS version associated with the operator version*.\n * **`bootstrapperImageSpec`**\": controls the bootstrapper container image. *The version must match the operator version*.\n * **`redisEnterpriseServicesRiggerImageSpec`**: controls the Service Rigger container image. *The version must match the operator version*.\n\nThe REC custom resource example below pulls all three container images from a GCR private registry:\n\n```YAML\napiVersion: app.redislabs.com/v1\nkind: RedisEnterpriseCluster\nmetadata:\n  name: rec\nspec:\n  nodes: 3\n  redisEnterpriseImageSpec:\n    imagePullPolicy: IfNotPresent\n    repository: gcr.io/yourproject/redislabs/redis\n    versionTag: 7.2.4-64\n  bootstrapperImageSpec:\n    imagePullPolicy: IfNotPresent\n    repository: gcr.io/yourproject/redislabs/operator\n    versionTag: 7.2.4-7\n  redisEnterpriseServicesRiggerImageSpec:\n    imagePullPolicy: IfNotPresent\n    repository: gcr.io/yourproject/redislabs/k8s-controller\n    versionTag: 7.2.4-7\n```\n\nIf your private container registry requires pull secrets, you must add `pullSecrets`\nto the `spec` section:\n\n```YAML\napiVersion: app.redislabs.com/v1\nkind: RedisEnterpriseCluster\nmetadata:\n  name: rec\nspec:\n  nodes: 3\n  pullSecrets:\n    - name: regcred\n  redisEnterpriseImageSpec:\n    imagePullPolicy: IfNotPresent\n    repository: gcr.io/yourproject/redislabs/redis\n    versionTag: 7.2.4-64\n  bootstrapperImageSpec:\n    imagePullPolicy: IfNotPresent\n    repository: gcr.io/yourproject/redislabs/operator\n    versionTag: 7.2.4-7\n  redisEnterpriseServicesRiggerImageSpec:\n    imagePullPolicy: IfNotPresent\n    repository: gcr.io/yourproject/redislabs/k8s-controller\n    versionTag: 7.2.4-7\n```\n\n## Rate limiting with DockerHub\n\nDocker has [rate limits for image pulls](https://www.docker.com/blog/scaling-docker-to-serve-millions-more-developers-network-egress/).\nAnonymous users are allowed a certain number of pulls every 6 hours. For authenticated users, the limit is larger.\nThese rate limits may affect your Kubernetes cluster in a number of ways:\n\n* The cluster nodes will likely be treated as a single anonymous user.\n* The number of pulls during a deployment might exceed the rate limit for other deployment dependencies, including the operator, Redis Enterprise Software, or other non-Redis pods.\n* Pull failures may prevent your deployment from downloading the required images in a timely manner. Delays here can affect the stability of deployments used by the Redis Enterprise operator.\n\nFor these reasons, you should seriously consider where your images\nare pulled from to **avoid failures caused by rate limiting**. The easiest solution\nis to push the required images to a private container registry under your control.\n",
  "tags": ["docs","operate","kubernetes"],
  "last_updated": "2026-04-08T12:21:52-07:00"
}