对容器映像使用私有注册表

本节详细介绍了如何将 Redis Enterprise Software 和 Kubernetes Operator 镜像配置为从各种来源提取。本页介绍如何为映像配置备用私有存储库，以及处理具有速率限制的公有存储库的一些技术。

适用于 Kubernetes 的 Redis Enterprise

Redis Enterprise Software、其 Kubernetes作员和 Service Rigger 都作为单独的容器映像分发。 您的 Kubernetes 部署将根据需要拉取这些映像。 您可以控制这些图像的位置 从 Operator 部署中拉取，也可以通过 Redis Enterprise 自定义资源。

通常，没有注册表域的部署的映像 name （例如gcr.io或localhost:5000） 从关联的默认注册表 与 Kubernetes 集群一起使用。对redislabs/redis可能会从 DockerHub 拉取 （OpenShift 除外，它从 Red Hat 中提取）。

出于安全原因（例如，在气隙环境中），您可能希望提取映像 从公共注册表中一次，然后将它们推送到 您的控制权。

警告：
要推送到私有注册表的镜像必须与原始镜像具有相同的版本标签，这一点非常重要。

此外，由于 Docker 速率限制了公共拉取，因此 您可能需要考虑从 private 注册表，以避免在达到 DockerHub 速率限制时部署失败。

以下信息将帮助您跟踪和配置部署拉取容器映像的位置。

注意：

重要

  • Redis Enterprise Operator 的每个版本都映射到 Redis Enterprise Software 的特定版本。语义版本始终匹配（例如，7.2.4），尽管具体版本号可能不同（例如，7.2.4-7 是 Redis Enterprise Software 7.2.4-64 的作员版本）。
  • 特定 Operator 版本仅支持特定的 Redis Enterprise 版本。不支持 operator 和 Redis Enterprise 版本的其他组合。

查找容器源

已部署应用程序中的每个 Pod 都有一个源注册表。任何没有注册表域名前缀的镜像（例如，“gcr.io”）都将从 Kubernetes 集群的默认注册表（即 DockerHub）中提取。您可以使用以下命令来发现集群上映像的拉取源。

要列出集群使用的所有镜像，请执行以下作：

kubectl get pods --all-namespaces -o jsonpath="{..image}" |tr -s '[[:space:]]' '\n' | uniq -c

To specifically determine the pull source for the Redis Enterprise operator itself, run the following command:

kubectl get pods --all-namespaces -o jsonpath="{..image}" |tr -s '[[:space:]]' '\n' | uniq -c | grep redislabs

You can limit this command to specific namespaces by replacing the --all-namespaces parameter with a set of -n {namespace} parameters, where each {namespace} is a specific namespace of interest on your cluster.

Create a private container registry

You can set up a private container registry in a couple of ways:

  • On-premise via Docker registry, Red Hat Quay, or other providers
  • Cloud provider based registries (e.g., Azure Container Registry, Google Container Registry, etc.).

Once you have set up a private container registry, you will identify the container registry using:

  • A domain name
  • A port (optional)
  • A repository path (optional)

Push images to a private container registry

Important images for a Redis Enterprise Software deployment include:

  • Redis Enterprise Software
  • Bootstrapping a Redis Enterprise cluster node (in the operator image)
  • The Service Rigger
  • The Redis Enterprise Software operator

You will need to push all these images to your private container registry. In general, to push the images you must:

  1. Pull the various images locally for the Redis Enterprise Software, the Service Rigger, and the operator.
  2. Tag the local images with the private container registry, repository, and version tag.
  3. Push the newly tagged images.

The example below shows the commands for pushing the images for Redis Enterprise Software and its operator to a private container registry:

PRIVATE_REPO=...your repo...
RS_VERSION=7.2.4-64
OPERATOR_VERSION=7.2.4-7
docker pull redislabs/redis:${RS_VERSION}
docker pull redislabs/operator:${OPERATOR_VERSION}
docker pull redislabs/k8s-controller:${OPERATOR_VERSION}
docker tag redislabs/redis:${RS_VERSION} ${PRIVATE_REPO}/redislabs/redis:${RS_VERSION}
docker tag redislabs/operator:${OPERATOR_VERSION} ${PRIVATE_REPO}/redislabs/operator:${OPERATOR_VERSION}
docker tag redislabs/k8s-controller:${OPERATOR_VERSION} ${PRIVATE_REPO}/redislabs/k8s-controller:${OPERATOR_VERSION}
docker push ${PRIVATE_REPO}/redislabs/redis:${RS_VERSION}
docker push ${PRIVATE_REPO}/redislabs/operator:${OPERATOR_VERSION}
docker push ${PRIVATE_REPO}/redislabs/k8s-controller:${OPERATOR_VERSION}

Configure deployments to use a private container registry

Once you push your images to your private container registry, you need to configure your deployments to use that registry for Redis Enterprise Software and operator deployments. The operator container image is configured directly by the operator deployment bundle. The Redis Enterprise cluster pod (RS and bootstrapper) and Service Rigger images are configured in the Redis Enterprise custom resource.

Depending on your Kubernetes platform, your private container registry may require authentication. If you do need authentication, add a pull secret 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.

Specify the operator image source

The operator bundle contains the operator deployment and the reference to the operator image (redislabs/operator). To use a private container registry, you must change 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.

In the operator deployment file, 'containers:image' should point to the same repository and tag you used when pushing to the private container registry:

${PRIVATE_REPO}/redislabs/operator:${OPERATOR_VERSION}

The example below specifies a 7.2.4-7 operator image in a Google Container Registry:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis-enterprise-operator
spec:
  replicas: 1
  selector:
    matchLabels:
      name: redis-enterprise-operator
  template:
    metadata:
      labels:
        name: redis-enterprise-operator
    spec:
      serviceAccountName: redis-enterprise-operator
      containers:
        - name: redis-enterprise-operator
          image: gcr.io/yourproject/redislabs/operator:7.2.4-7
...

If your container registry requires a pull secret, configure imagePullSecrets on the operator deployment:

spec:
  template:
    spec:
      imagePullSecrets:
      - name: regcred

Specify the Redis Enterprise cluster images source

A Redis Enterprise cluster managed by the operator consists of three container images:

  • redislabs/redis: the Redis Enterprise Software container image
  • redislabs/operator: the bootstrapper is packaged within the operator container image
  • redislabs/k8s-controller: the Service Rigger container image

By default, a new Redis Enterprise cluster is created using the container images listed above. These container images are pulled from the K8s cluster's default container registry.

To pull the Redis Enterprise container images from a private container registry, you must specify them in the Redis Enterprise cluster custom resource.

Add the following sections to the spec section of your RedisEnterpriseCluster resource file:

  • redisEnterpriseImageSpec: controls the Redis Enterprise Software container image. The version should match the RS version associated with the operator version.
  • bootstrapperImageSpec": controls the bootstrapper container image. The version must match the operator version.
  • redisEnterpriseServicesRiggerImageSpec: controls the Service Rigger container image. The version must match the operator version.

The REC custom resource example below pulls all three container images from a GCR private registry:

apiVersion: app.redislabs.com/v1
kind: RedisEnterpriseCluster
metadata:
  name: rec
spec:
  nodes: 3
  redisEnterpriseImageSpec:
    imagePullPolicy: IfNotPresent
    repository: gcr.io/yourproject/redislabs/redis
    versionTag: 7.2.4-64
  bootstrapperImageSpec:
    imagePullPolicy: IfNotPresent
    repository: gcr.io/yourproject/redislabs/operator
    versionTag: 7.2.4-7
  redisEnterpriseServicesRiggerImageSpec:
    imagePullPolicy: IfNotPresent
    repository: gcr.io/yourproject/redislabs/k8s-controller
    versionTag: 7.2.4-7

If your private container registry requires pull secrets, you must add pullSecrets to the spec section:

apiVersion: app.redislabs.com/v1
kind: RedisEnterpriseCluster
metadata:
  name: rec
spec:
  nodes: 3
  pullSecrets:
    - name: regcred
  redisEnterpriseImageSpec:
    imagePullPolicy: IfNotPresent
    repository: gcr.io/yourproject/redislabs/redis
    versionTag: 7.2.4-64
  bootstrapperImageSpec:
    imagePullPolicy: IfNotPresent
    repository: gcr.io/yourproject/redislabs/operator
    versionTag: 7.2.4-7
  redisEnterpriseServicesRiggerImageSpec:
    imagePullPolicy: IfNotPresent
    repository: gcr.io/yourproject/redislabs/k8s-controller
    versionTag: 7.2.4-7

Rate limiting with DockerHub

Docker has rate limits for image pulls. Anonymous users are allowed a certain number of pulls every 6 hours. For authenticated users, the limit is larger. These rate limits may affect your Kubernetes cluster in a number of ways:

  • The cluster nodes will likely be treated as a single anonymous user.
  • 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.
  • 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.

For these reasons, you should seriously consider where your images are pulled from to avoid failures caused by rate limiting. The easiest solution is to push the required images to a private container registry under your control.

RATE THIS PAGE
Back to top ↑