title: Use a private registry for 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.

title: Overview

text:
Redis Enterprise Software, its Kubernetes operator, and the Service Rigger
are all distributed as separate container images.
Your Kubernetes deployment will pull these images as needed.
You can control where these images are
pulled from within the operator deployment and also via the
Redis Enterprise custom resources.

The operator image also includes the admission controller, which runs as part of the operator container and provides validation for Redis Enterprise database resources.

In general, images for deployments that do not have a registry domain
name (e.g., `gcr.io` or `localhost:5000`) are pulled from the default registry associated
with the Kubernetes cluster. A plain reference to `redislabs/redis` will likely pull from DockerHub
(except on OpenShift where it pulls from Red Hat).

For security reasons (e.g., in air-gapped environments), you may want to pull the images
from a public registry once and then push them to a private registry under
your control.

It is very important that the images you are pushing to the private registry have the same exact version tag as the original images.

Furthermore, because [Docker rate limits public pulls](https://www.docker.com/blog/scaling-docker-to-serve-millions-more-developers-network-egress/),
you may want to consider pulling images from a
private registry to avoid deployment failures when you hit your DockerHub rate limit.

The information below will help you track and configure where your deployments pull container images.

**IMPORTANT**
* 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.22.0), although the specific release numbers may be different (for example, 7.22.0-7 is the operator version for Redis Enterprise Software 7.22.0-28).
* A specific operator version only supports a specific Redis Enterprise version. Other combinations of operator and Redis Enterprise versions are **not supported**.

title: Find container sources

text:
Every 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.

To list all the images used by your cluster:

[code example]

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

[code example]

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.

title: Create a private container registry

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

* 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
* 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)

title: Push images to a private container registry

text:
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 (which also includes the admission controller)

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

 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.
 2. Tag the local images with the private container registry, repository, and version tag.
 3. [Push](https://docs.docker.com/engine/reference/commandline/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:

[code example]

title: Configure deployments to use a private container registry

text:
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](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.

title: Specify the operator image source

text:
The operator bundle contains the operator deployment and the reference to the operator image (`redislabs/operator`). This image includes both the operator functionality and the admission controller. 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:

[code example]

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

[code example]

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

[code example]

title: Specify the Redis Enterprise cluster images source

text:
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](https://docs.docker.com/engine/reference/commandline/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:

[code example]

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

[code example]

title: Admission controller

text:
The admission controller is included as part of the operator container image and does not require a separate container image. When you configure a private container registry for the operator image, the admission controller functionality is automatically included.

The admission controller runs within the operator pod and provides validation for Redis Enterprise database resources. It exposes an HTTPS endpoint on port 8443 that Kubernetes uses to validate resource configurations before they are applied to the cluster.

For more information about configuring the admission controller, see [Enable the admission controller]().

title: Rate limiting with DockerHub

text:
Docker has [rate limits for image pulls](https://www.docker.com/blog/scaling-docker-to-serve-millions-more-developers-network-egress/).
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.

section_id: find-container-sources

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

code:
PRIVATE_REPO=...your repo...
RS_VERSION=7.22.0-28
OPERATOR_VERSION=7.22.0-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}

section_id: specify-the-operator-image-source

code:
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.22.0-7
...

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

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

code:
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.22.0-28
  bootstrapperImageSpec:
    imagePullPolicy: IfNotPresent
    repository: gcr.io/yourproject/redislabs/operator
    versionTag: 7.22.0-7
  redisEnterpriseServicesRiggerImageSpec:
    imagePullPolicy: IfNotPresent
    repository: gcr.io/yourproject/redislabs/k8s-controller
    versionTag: 7.22.0-7


title: Install Redis Enterprise Helm chart

summary: Install Redis Enterprise for Kubernetes version 7.8.6 using Helm charts.

page_type: content

title: Overview

role: overview

text: Helm charts provide a simple way to install the Redis Enterprise for Kubernetes operator in just a few steps. For more information about Helm, go to [https://helm.sh/docs/](https://helm.sh/docs/).

title: Prerequisites

role: content

text:
- A [supported distribution]() of Kubernetes.
- At least three worker nodes.
- [Kubernetes client (kubectl)](https://kubernetes.io/docs/tasks/tools/).
- [Helm 3.10 or later](https://helm.sh/docs/intro/install/)
    or 3.18 for migrating from a non-Helm installation.

If you suspect your file descriptor limits are below 100,000, you must either manually increase limits or [Allow automatic resource adjustment](). Most major cloud providers and standard container runtime configurations set default file descriptor limits well above the minimum required by Redis Enterprise. In these environments, you can safely run without enabling automatic resource adjustment.

title: Example values

role: example

text:
The steps below use the following placeholders to indicate command line parameters you must provide:

- `<repo-name>` is the name of the repo holding your Helm chart (example: `redis`).
- `<release-name>` is the name you give a specific installation of the Helm chart (example: `my-redis-enterprise-operator`)
- `<chart-version>` is the version of the Helm chart you are installing (example: `7.8.2-2`)
- `<namespace-name>` is the name of the new namespace the Redis operator will run in (example: `ns1`)
- `<path-to-chart>` is the filepath to the Helm chart, if it is stored in a local directory (example: `/home/charts/redis-enterprise-operator`)

title: Install

role: setup

text:
1. Add the Redis repository.

   [code example]

2. Install the Helm chart into a new namespace.

[code example]

To install with Openshift, add `--set openshift.mode=true`.

To monitor the installation add the `--debug` flag. The installation runs several jobs synchronously and may take a few minutes to complete.

title: Install from local directory

text:
1. Find the latest release on the [redis-enterprise-k8s-docs](https://github.com/RedisLabs/redis-enterprise-k8s-docs/releases) repo and download the `tar.gz` source code into a local directory.

2. Install the Helm chart from your local directory.

[code example]

To install with Openshift, add `--set openshift.mode=true`.

To monitor the installation add the `--debug` flag. The installation runs several jobs synchronously and may take a few minutes to complete.

title: Specify values during install

text:
1. View configurable values with `helm show values <repo-name>/redis-enterprise-operator`.

2. Install the Helm chart, overriding specific value defaults using `--set`.

[code example]

title: Install with values file

text:
1. View configurable values with `helm show values <repo-name>/redis-enterprise-operator`.

2. Create a YAML file to specify the values you want to configure.

3. Install the chart with the `--values` option.

[code example]

title: Migrate from a non-Helm installation

text:
To migrate an existing non-Helm installation of the Redis Enterprise operator to a Helm-based installation:

1. [Upgrade]() your existing Redis Enterprise operator to match the version of the Helm chart you want to install. Use the same non-Helm method you used for the original installation.

2. [Install](#install) the Helm chart adding the `--take-ownership` flag:

   [code example]

   - The `--take-ownership` flag is available with Helm versions 3.18 or later.
   - This flag is only needed for the first installation of the chart. Subsequent upgrades don't require this flag.
   - Use the `helm install` command, not `helm upgrade`.

3. Delete the old `ValidatingWebhookConfiguration` object from the previous non-Helm installation:

   [code example]

   This step is only needed when the `admission.limitToNamespace` chart value is set to `true` (the default). In this case, the webhook object installed by the chart is named `redis-enterprise-admission-<namespace>`, and the original webhook object, named `redis-enterprise-admission`, becomes redundant. If `admission.limitToNamespace` is set to `false`, the webhook installed by the chart is named `redis-enterprise-admission`, and the existing webhook object is reused.

title: Upgrade the chart

text:
To upgrade an existing Helm chart installation:

[code example]

You can also upgrade from a local directory:

[code example]

For example, to upgrade a chart with the release name `my-redis-enterprise` from the chart's root directory:

[code example]

To upgrade with OpenShift, add `--set openshift.mode=true`.

The upgrade process automatically updates the operator and its components, including the Custom Resource Definitions (CRDs). The CRDs are versioned and update only if the new version is higher than the existing version.

After you upgrade the operator, you might need to upgrade your Redis Enterprise clusters, depending on the Redis software version bundled with the operator. For detailed information about the upgrade process, see [Redis Enterprise for Kubernetes upgrade documentation](https://redis.io/docs/latest/operate/kubernetes/upgrade/).

If your databases use user-defined modules (custom non-bundled modules), you must take additional steps during the upgrade process. See [Upgrade with user-defined modules]() for details.

For more information and options when upgrading charts, see [helm upgrade](https://helm.sh/docs/helm/helm_upgrade/).

title: Uninstall

text:
1. Delete any custom resources managed by the operator. See [Delete custom resources]() for detailed steps. You must delete custom resources in the correct order to avoid errors.

2. Uninstall the Helm chart.

[code example]

This removes all Kubernetes resources associated with the chart and deletes the release.

Custom Resource Definitions (CRDs) installed by the chart are not removed during chart uninstallation. To remove them manually after uninstalling the chart, run `kubectl delete crds -l app=redis-enterprise`.

title: Known limitations

text:
- The steps for [creating the RedisEnterpriseCluster (REC)]() and other custom resources remain the same.
- The chart doesn't include configuration options for multiple namespaces, rack-awareness, and Vault integration. The steps for configuring these options remain the same.
- The chart has had limited testing in advanced setups, including Active-Active configurations, air-gapped deployments, and IPv6/dual-stack environments.

code: helm repo add <repo-name> https://helm.redis.io

section_id: install

code:
helm install <release-name> <repo-name>/redis-enterprise-operator \
    --version <chart-version> \
    --namespace <namespace-name> \
    --create-namespace

code:
helm install <release-name> <path-to-chart> \
    --namespace <namespace-name> \
    --create-namespace

section_id: install-from-local-directory

code:
helm install <operator-name> <repo-name>/redis-enterprise-operator \
    --version <chart-version> \
    --namespace <namespace-name> \
    --create-namespace
    --set <key1>=<value1> \
    --set <key2>=<value2>

section_id: specify-values-during-install

code:
helm install <operator-name> <repo-name>/redis-enterprise-operator \
    --version <chart-version> \
    --namespace <namespace-name> \
    --create-namespace \
    --values <path-to-values-file>

section_id: install-with-values-file

code: helm install <release-name> <repo-name>/redis-enterprise-operator --take-ownership

section_id: migrate-from-a-non-helm-installation

code: kubectl delete validatingwebhookconfiguration redis-enterprise-admission

code: helm upgrade <release-name> <repo-name>/redis-enterprise-operator --version <chart-version>

section_id: upgrade-the-chart

code: helm upgrade <release-name> <path-to-chart>

code: helm upgrade my-redis-enterprise .

code: helm uninstall <release-name>

section_id: uninstall


title: Deployment

summary: Deploy Redis Enterprise for Kubernetes using the Redis Enterprise operator on various Kubernetes distributions.

summary: How to install Redis Enterprise Software for Kubernetes.

title: Deploy Redis Enterprise Software for Kubernetes

title: Install Redis Enterprise Helm chart

summary: A quick introduction to the steps necessary to get a Redis Enterprise cluster installed in your OpenShift Kubernetes cluster

title: Deploy Redis Enterprise for Kubernetes with OpenShift

title: Overview

text:
Deploy Redis Enterprise for Kubernetes by using the Redis Enterprise operator. The operator provides a simple way to deploy and manage Redis Enterprise clusters on various Kubernetes distributions, both on-premises and in the cloud.

The Redis Enterprise operator uses custom resource definitions (CRDs) to manage Redis Enterprise clusters (REC) and databases (REDB) as native Kubernetes resources. This approach enables GitOps workflows and Kubernetes-native operations.

title: Quick start

text:
Get started quickly with a basic Redis Enterprise deployment:

- [Deploy Redis Enterprise for Kubernetes]() - Step-by-step guide for most Kubernetes distributions
- [Deploy on OpenShift]() - Specific instructions for OpenShift environments

title: Deployment methods

text:
Choose the deployment method that best fits your environment:

- [Deploy with Helm]() - Use Helm charts for simplified deployment and management
- [Deploy with operator bundle]() - Direct deployment using kubectl and operator manifests

title: Container images

text:
Understand the container images used by the Redis Enterprise operator:

- [Container images]() - Details about Redis Enterprise container images and registries

title: Compatibility

role: compatibility

text:
Before installing, verify compatibility with your environment:

- [Supported Kubernetes distributions]() - Check which Redis Enterprise operator version supports your Kubernetes distribution

title: Prerequisites

text:
Before deploying Redis Enterprise for Kubernetes, ensure you have:

- A Kubernetes cluster running a [supported distribution]()
- Minimum of three worker nodes for high availability
- Kubernetes client (kubectl) configured to access your cluster
- Access to container registries (DockerHub, Red Hat Container Catalog, or private registry)
- Sufficient resources as outlined in [sizing recommendations]()

title: Next steps

text:
After deployment, you can:

- [Create a Redis Enterprise cluster (REC)]()
- [Create Redis Enterprise databases (REDB)]()
- [Configure networking]()
- [Set up security]()


summary: Redis Enterprise for Kubernetes and cluster can be installed via CLI tools OpenShift

title: Deployment with OpenShift CLI for Redis Enterprise for Kubernetes

summary: OpenShift provides the OperatorHub where you can install the Redis Enterprise operator from the administrator user interface.

title: Deploy Redis Enterprise with OpenShift OperatorHub

title: Overview

text:
The deployment of Redis Enterprise clusters is managed with the Redis Enterprise operator that you deploy in the namespace for your project.
To create a database that your application
workloads can use:

1. Install the Redis Enterprise operator.

1. Create a Redis Enterprise CRD to describe your desired cluster.

1. The operator reads this cluster description and deploys the various components on your K8s cluster.

1. Once running, use the Redis Enterprise cluster to create a database.

1. The operator automatically exposes the new database as a K8s service.

title: For OpenShift via the OperatorHub

text: To [create a database on an OpenShift 4.x cluster via the OperatorHub]() you only need to have the [OpenShift 4.x cluster installed](https://docs.openshift.com/container-platform/4.3/welcome/index.html) with at least three nodes that each meet the [minimum requirements for a development installation]().

title: For OpenShift via the CLI

text:
To [create a database on an OpenShift cluster via the CLI](), you need:

1. An [OpenShift cluster installed](https://docs.openshift.com/container-platform/4.3/welcome/index.html) with at least three nodes that each meet the [minimum requirements for a development installation]().
1. The [kubectl package installed](https://kubernetes.io/docs/tasks/tools/install-kubectl/) at version 1.9 or higher
1. The [OpenShift cli installed](https://docs.openshift.com/container-platform/4.2/cli_reference/openshift_cli/getting-started-cli.html)

title: Version compatibility

text: To see which version of Redis Enterprise for Kubernetes supports your OpenShift version, see [Supported Kubernetes distributions]().


title: Overview

text: Use these steps to set up a Redis Enterprise Software cluster with OpenShift.

title: Prerequisites

text:
- [OpenShift cluster](https://docs.openshift.com/container-platform/4.8/installing/index.html) with at least 3 nodes (each meeting the [minimum requirements for a development installation]())
- [OpenShift CLI](https://docs.openshift.com/container-platform/latest/cli_reference/openshift_cli/getting-started-cli.html)

To see which version of Redis Enterprise for Kubernetes supports your OpenShift version, see [Supported Kubernetes distributions]().

If you suspect your file descriptor limits are below 100,000, you must either manually increase limits or [Allow automatic resource adjustment](). Most major cloud providers and standard container runtime configurations set default file descriptor limits well above the minimum required by Redis Enterprise. In these environments, you can safely run without enabling automatic resource adjustment.

title: Deploy the operator

text:
1. Create a new project.

    [code example]

1. Verify the newly created project.

    [code example]

1. Get the deployment files.

    [code example]

1. Deploy the OpenShift operator bundle.

    If you are using version 6.2.18-41 or earlier, you must [apply the security context constraint](#install-security-context-constraint) before the operator bundle.

    [code example]

Changes to the `openshift.bundle.yaml` file can cause unexpected results.

1. Verify that your `redis-enterprise-operator` deployment is running.

    [code example]

    A typical response looks like this:

    [code example]

DO NOT modify or delete the StatefulSet created during the deployment process. Doing so could destroy your Redis Enterprise cluster (REC).

title: Security context constraints

role: security

text: Versions 7.22.0-6 and later run in without permissions to [allow automatic resource adjustment](). If you use the recommended default security constraints, remove the existing `redis-enterprise-scc-v2` SCC and unbind it from the REC service account after upgrading.

title: Create a Redis Enterprise cluster custom resource

text:
1. Apply the `RedisEnterpriseCluster` resource file ([rec_rhel.yaml](https://github.com/RedisLabs/redis-enterprise-k8s-docs/blob/master/openshift/rec_rhel.yaml)).

    You can rename the file to `<your_cluster_name>.yaml`, but it is not required. Examples below use `<rec_rhel>.yaml`. [Options for Redis Enterprise clusters]() has more info about the Redis Enterprise cluster (REC) custom resource, or see the [Redis Enterprise cluster API]() for a full list of options.

If you suspect your file descriptor limits are below 100,000, you must either manually increase limits or [Allow automatic resource adjustment](). Most major cloud providers and standard container runtime configurations set default file descriptor limits well above the minimum required by Redis Enterprise. In these environments, you can safely run without enabling automatic resource adjustment.

    The REC name cannot be changed after cluster creation.

Each Redis Enterprise cluster requires at least 3 nodes. Single-node RECs are not supported.

2. Apply the custom resource file to create your Redis Enterprise cluster.

If you enabled automatic resource adjustment in your configuration, this step will trigger the operator to apply elevated capabilities. Ensure your security context allows it.

    [code example]

    The operator typically creates the REC within a few minutes.

1. Check the cluster status.

    [code example]

    You should receive a response similar to the following:

    [code example]

title: Configure the admission controller

role: configuration

title: Limit the webhook to relevant namespaces

role: limits

text:
If not limited, the webhook intercepts requests from all namespaces. If you have several REC objects in your Kubernetes cluster, limit the webhook to the relevant namespaces. If you aren't using multiple namespaces, skip this step.

1. Verify your namespace is labeled and the label is unique to this namespace, as shown in the next example.

    [code example]

1. Patch the webhook spec with the `namespaceSelector` field.

    [code example]

1. Apply the patch.

    [code example]

For releases before 6.4.2-4, use this command instead:

[code example]

The 6.4.2-4 release introduces a new `ValidatingWebhookConfiguration` to replace `redb-admission`. See the [6.4.2-4 release notes]().

title: Verify admission controller installation

text:
Apply an invalid resource as shown below to force the admission controller to reject it. If it applies successfully, the admission controller is not installed correctly.

[code example]

You should see this error from the admission controller webhook `redisenterprise.admission.redislabs`.

[code example]

title: Create a Redis Enterprise database custom resource

text:
The operator uses the instructions in the Redis Enterprise database (REDB) custom resources to manage databases on the Redis Enterprise cluster.

1. Create a `RedisEnterpriseDatabase` custom resource.

    This example creates a test database. For production databases, see [create a database]() and [RedisEnterpriseDatabase API reference]().

    [code example]

1. Apply the newly created REDB resource.

    [code example]

title: More info

text:
- [Redis Enterprise cluster API]()
- [Redis Enterprise database API]()

code: oc new-project <your-project-name>

section_id: deploy-the-operator

code: oc project <your-project-name>

code: oc apply -f openshift.bundle.yaml

code: oc get deployment

code:
NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
    redis-enterprise-operator   1/1     1            1           0m36s

code: oc apply -f <rec_rhel>.yaml

code: oc get pod

code:
apiVersion: v1
    kind: Namespace
    metadata:
      labels:
       namespace-name: staging
    name: staging

code:
cat > modified-webhook.yaml <<EOF
    webhooks:
    - name: redisenterprise.admission.redislabs
      namespaceSelector:
       matchLabels:
         namespace-name: staging
    EOF

code:
oc patch ValidatingWebhookConfiguration \
      redis-enterprise-admission --patch "$(cat modified-webhook.yaml)"

code:
oc patch ValidatingWebhookConfiguration \
  redb-admission --patch "$(cat modified-webhook.yaml)"

code:
oc apply -f - << EOF
apiVersion: app.redislabs.com/v1alpha1
kind: RedisEnterpriseDatabase
metadata:
  name: redis-enterprise-database
spec:
  evictionPolicy: illegal
EOF

code: Error from server: error when creating "STDIN": admission webhook "redisenterprise.admission.redislabs" denied the request: eviction_policy: u'illegal' is not one of [u'volatile-lru', u'volatile-ttl', u'volatile-random', u'allkeys-lru', u'allkeys-random', u'noeviction', u'volatile-lfu', u'allkeys-lfu']

code:
cat << EOF > /tmp/redis-enterprise-database.yml
    apiVersion: app.redislabs.com/v1alpha1
    kind: RedisEnterpriseDatabase
    metadata:
      name: redis-enterprise-database
    spec:
      memorySize: 100MB
    EOF

code: oc apply -f /tmp/redis-enterprise-database.yml


title: Overview

text:
You can deploy Redis Enterprise for Kubernetes from the Red Hat OpenShift CLI. You can also use a UI, [OperatorHub](https://docs.openshift.com/container-platform/4.11/operators/index.html) (Red Hat) to install operators and create custom resources.

If you suspect your file descriptor limits are below 100,000, you must either manually increase limits or [Allow automatic resource adjustment](). Most major cloud providers and standard container runtime configurations set default file descriptor limits well above the minimum required by Redis Enterprise. In these environments, you can safely run without enabling automatic resource adjustment.

To see which version of Redis Enterprise for Kubernetes supports your OpenShift version, see [Supported Kubernetes distributions]().

title: Install the Redis Enterprise operator

text:
If using version 6.2.18-41 or earlier, [Install the security context constraint](#install-security-context-constraint) before installing the operator.

1. Select **Operators > OperatorHub**.

2. Search for _Redis Enterprise_ in the search dialog and select the **Redis Enterprise Operator provided by Redis** marked as **Certified**.

    By default, the image is pulled from Red Hat's registry.

3. On the **Install Operator** page, specify the namespace for the operator.

    Only one namespace per operator is supported.

4. Update the **channel** with the version you're installing.

    For more information about specific versions, see the [release notes]().

5. Choose an approval strategy.

    Use **Manual** for production systems to ensure the operator is only upgraded by approval.

6. Select **Install** and approve the install plan.

   You can monitor the subscription status in **Operators > Installed Operators**.

DO NOT modify or delete the StatefulSet created during the deployment process. Doing so could destroy your Redis Enterprise cluster (REC).

title: Security context constraints

title: Create Redis Enterprise custom resources

text:
The **Installed Operators**->**Operator details** page shows the provided APIs: **RedisEnterpriseCluster** and **RedisEnterpriseDatabase**. You can select **Create instance** to create custom resources using the OperatorHub interface.

Use the YAML view to create a custom resource file or let OperatorHub generate the YAML file for you by specifying your configuration options in the form view.

If you suspect your file descriptor limits are below 100,000, you must either manually increase limits or [Allow automatic resource adjustment](). Most major cloud providers and standard container runtime configurations set default file descriptor limits well above the minimum required by Redis Enterprise. In these environments, you can safely run without enabling automatic resource adjustment.

<note> The REC name cannot be changed after cluster creation.</note>

For more information on creating and maintaining Redis Enterprise custom resources, see [Redis Enterprise clusters (REC)]() and [Redis Enterprise databases (REDB)]().


title: Overview

text:
To deploy Redis Enterprise Software for Kubernetes and start your Redis Enterprise cluster (REC), you need to do the following:

- Create a new namespace in your Kubernetes cluster.
- Download the operator bundle.
- Apply the operator bundle and verify it's running.
- Create a Redis Enterprise cluster (REC).

This guide works with most supported Kubernetes distributions. If you're using OpenShift, see [Redis Enterprise on OpenShift](). For details on what is currently supported, see [supported distributions]().

title: Prerequisites

text:
To deploy Redis Enterprise for Kubernetes, you'll need:

- Kubernetes cluster in a [supported distribution]()
- minimum of three worker nodes
- Kubernetes client (kubectl)
- access to DockerHub, RedHat Container Catalog, or a private repository that can hold the required images.

If you suspect your file descriptor limits are below 100,000, you must either manually increase limits or [Allow automatic resource adjustment](). Most major cloud providers and standard container runtime configurations set default file descriptor limits well above the minimum required by Redis Enterprise. In these environments, you can safely run without enabling automatic resource adjustment.

If you are applying version 7.8.2-6 or above, check if the [OS](https://redis.io/docs/latest/operate/kubernetes/release-notes/7-8-2-releases/7-8-2-6-nov24/#breaking-changes) installed on the node is supported.

title: Create a new namespace

text:
**Important:** Each namespace can only contain one Redis Enterprise cluster. Multiple RECs with different operator versions can coexist on the same Kubernetes cluster, as long as they are in separate namespaces.

Throughout this guide, each command is applied to the namespace in which the Redis Enterprise cluster operates.

1. Create a new namespace

    [code example]

1. Change the namespace context to make the newly created namespace default for future commands.

    [code example]

You can use an existing namespace as long as it does not contain any existing Redis Enterprise cluster resources. It's best practice to create a new namespace to make sure there are no Redis Enterprise resources that could interfere with the deployment.

title: Install the operator

text:
Redis Enterprise for Kubernetes bundle is published as a container image. A list of required images is available in the [release notes]() for each version.

The operator [definition and reference materials](https://github.com/RedisLabs/redis-enterprise-k8s-docs) are available on GitHub. The operator definitions are [packaged as a single generic YAML file](https://github.com/RedisLabs/redis-enterprise-k8s-docs/blob/master/bundle.yaml).

If you do not pull images from DockerHub or another public registry, you need to use a [private container registry]().

title: Download the operator bundle

text:
Pull the latest version of the operator bundle:

[code example]

  If you need a different release, replace `VERSION` with a specific release tag.

  Check version tags listed with the [operator releases on GitHub](https://github.com/RedisLabs/redis-enterprise-k8s-docs/releases) or by [using the GitHub API](https://docs.github.com/en/rest/reference/repos#releases) to ensure the version of the bundle is correct.

title: Deploy the operator bundle

text:
Apply the operator bundle in your REC namespace:

[code example]

  You should see a result similar to this:

  [code example]

DO NOT modify or delete the StatefulSet created during the deployment process. Doing so could destroy your Redis Enterprise cluster (REC).

#### Verify the operator is running

Check the operator deployment to verify it's running in your namespace:

[code example]

You should see a result similar to this:

[code example]

title: Create a Redis Enterprise cluster (REC)

text:
A Redis Enterprise cluster (REC) is created from a `RedisEnterpriseCluster` custom resource
that contains cluster specifications.

The following example creates a minimal Redis Enterprise cluster. See the [RedisEnterpriseCluster API reference]() for more information on the various options available.

If you suspect your file descriptor limits are below 100,000, you must either manually increase limits or [Allow automatic resource adjustment](). Most major cloud providers and standard container runtime configurations set default file descriptor limits well above the minimum required by Redis Enterprise. In these environments, you can safely run without enabling automatic resource adjustment.

1. Create a file that defines a Redis Enterprise cluster with three nodes.

The REC name (`my-rec` in this example) cannot be changed after cluster creation.

    [code example]

   This will request a cluster with three Redis Enterprise nodes using the default requests (i.e., 2 CPUs and 4GB of memory per node).

   To test with a larger configuration, use the example below to add node resources to the `spec` section of your test cluster (`my-rec.yaml`).

    [code example]

Each cluster must have at least 3 nodes. Single-node RECs are not supported.

    See the [Redis Enterprise hardware requirements]() for more information on sizing Redis Enterprise node resource requests.

If you enabled automatic resource adjustment in your configuration, this step will trigger the operator to apply elevated capabilities. Ensure your security context allows it.

1. Apply your custom resource file in the same namespace as `my-rec.yaml`.

    [code example]

   You should see a result similar to this:

   [code example]

1. You can verify the creation of the cluster with:

    [code example]

    You should see a result similar to this:

    [code example]

    At this point, the operator will go through the process of creating various services and pod deployments.

    You can track the progress by examining the StatefulSet associated with the cluster:

    [code example]

    or by looking at the status of all of the resources in your namespace:

    [code example]

title: Enable the admission controller

text:
The admission controller dynamically validates REDB resources configured by the operator. It is strongly recommended that you use the admission controller on your Redis Enterprise Cluster (REC). The admission controller only needs to be configured once per operator deployment.

As part of the REC creation process, the operator stores the admission controller certificate in a Kubernetes secret called `admission-tls`. You may have to wait a few minutes after creating your REC to see the secret has been created.

title: Limit the webhook to the relevant namespaces {#webhook}

text:
The operator bundle includes a webhook file. The webhook will intercept requests from all namespaces unless you edit it to target a specific namespace. You can do this by adding the `namespaceSelector` section to the webhook spec to target a label on the namespace.

1. Make sure the namespace has a unique `namespace-name` label.

    [code example]

1. Patch the webhook to add the `namespaceSelector` section.

    [code example]

1. Apply the patch.

    [code example]

title: Verify the admission controller is working

text:
1. Verify the admission controller is installed correctly by applying an invalid resource. This should force the admission controller to correct it.

    [code example]

    You should see your request was denied by the `admission webhook "redisenterprise.admission.redislabs"`.

    [code example]

title: Add user-defined modules (optional)

text:
If you plan to create databases that use user-defined modules (custom non-bundled modules), you must add them to the REC custom resource before creating the databases.

See [User-defined modules]() for detailed instructions on adding and configuring custom modules.

title: Create a Redis Enterprise Database (REDB)

text:
You can create multiple databases within the same namespace as your REC or in other namespaces.

See [manage Redis Enterprise databases for Kubernetes]() to create a new REDB.

code: kubectl create namespace <rec-namespace>

section_id: create-a-new-namespace

code: kubectl config set-context --current --namespace=<rec-namespace>

code: VERSION=`curl --silent https://api.github.com/repos/RedisLabs/redis-enterprise-k8s-docs/releases/latest | grep tag_name | awk -F'"' '{print $4}'`

section_id: download-the-operator-bundle

code: kubectl apply -f https://raw.githubusercontent.com/RedisLabs/redis-enterprise-k8s-docs/$VERSION/bundle.yaml

section_id: deploy-the-operator-bundle

code:
role.rbac.authorization.k8s.io/redis-enterprise-operator created
  serviceaccount/redis-enterprise-operator created
  rolebinding.rbac.authorization.k8s.io/redis-enterprise-operator created
  customresourcedefinition.apiextensions.k8s.io/redisenterpriseclusters.app.redislabs.com configured
  customresourcedefinition.apiextensions.k8s.io/redisenterprisedatabases.app.redislabs.com configured
  deployment.apps/redis-enterprise-operator created

code: kubectl get deployment redis-enterprise-operator

code:
NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
redis-enterprise-operator   1/1     1            1           0m36s

code:
cat <<EOF > my-rec.yaml
    apiVersion: "app.redislabs.com/v1"
    kind: "RedisEnterpriseCluster"
    metadata:
      name: my-rec
    spec:
      nodes: 3
    EOF

section_id: create-a-redis-enterprise-cluster-rec

code:
redisEnterpriseNodeResources:
      limits:
        cpu: 2000m
        memory: 16Gi
      requests:
        cpu: 2000m
        memory: 16Gi

code: kubectl apply -f my-rec.yaml

code: kubectl get rec

code:
NAME           AGE
    my-rec   1m

code: kubectl rollout status sts/my-rec

code: kubectl get all

code:
apiVersion: v1
    kind: Namespace
    metadata:
      name: example-ns
      labels:
        namespace-name: example-ns

code:
cat > modified-webhook.yaml <<EOF
    webhooks:
    - name: redisenterprise.admission.redislabs
      namespaceSelector:
        matchLabels:
          namespace-name: example-ns
    EOF

code:
kubectl patch ValidatingWebhookConfiguration \
      redis-enterprise-admission --patch "$(cat modified-webhook.yaml)"

code:
kubectl apply -f - << EOF
    apiVersion: app.redislabs.com/v1alpha1
    kind: RedisEnterpriseDatabase
    metadata:
      name: redis-enterprise-database
    spec:
      evictionPolicy: illegal
    EOF


title: Use Auto Tiering on Kubernetes

summary: Deploy a cluster with Auto Tiering on Kubernetes.

title: Overview

text: This page applies to Redis database version 7.4 and earlier. If you use version 8.0 or later, see [Redis Flex](https://redis.io/docs/latest/operate/kubernetes/re-clusters/redis-flex).

title: Prerequisites

text:
Redis Enterprise Software for Kubernetes supports using Auto Tiering (previously known as Redis on Flash), which extends your node memory to use both RAM and flash storage. SSDs (solid state drives) can store infrequently used (warm) values while your keys and frequently used (hot) values are still stored in RAM. This improves performance and lowers costs for large datasets.

NVMe (non-volatile memory express) SSDs are strongly recommended to achieve the best performance.

Before creating your Redis clusters or databases, these SSDs must be:

- [locally attached to worker nodes in your Kubernetes cluster](https://kubernetes.io/docs/concepts/storage/volumes/#local)
- formatted and mounted on the nodes that will run Redis Enterprise pods
- dedicated to Auto Tiering and not shared with other parts of the database, (e.g. durability, binaries)
- [provisioned as local persistent volumes](https://kubernetes.io/docs/concepts/storage/volumes/#local)
  - You can use a [local volume provisioner](https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner/blob/master/README.md) to do this [dynamically](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#dynamic)
- a [StorageClass](https://kubernetes.io/docs/concepts/storage/storage-classes/#local) resource with a unique name

For more information on node storage, see [Node persistent and ephemeral storage]().

title: Create a Redis Enterprise cluster

text:
To deploy a Redis Enterprise cluster (REC) with Auto Tiering, you'll need to specify the following in the `redisOnFlashSpec` section of your [REC custom resource]():

- enable Auto Tiering (`enabled: true`)
- flash storage driver (`bigStoreDriver`)
  - `rocksdb` or `speedb`(default)
- storage class name (`storageClassName`)
- minimal flash disk size (`flashDiskSize`)

 Clusters upgraded to version 7.2.4-2 from an earlier version will change the `bigStoreDriver` (previously called `flashStorageEngine`) to the new default `speedb`, regardless of previous configuration.

Switching between storage engines (`speedb` and `rocksdb`) requires guidance by Redis Support or your Account Manager.

PVC expansion is not supported when using Auto Tiering. Do not enable `enablePersistentVolumeResize` in the REC `persistentSpec` if you are using `redisOnFlashSpec` as this will result in conflicts.

Here is an example of an REC custom resource with these attributes:

[code example]

title: Create a Redis Enterprise database

text:
By default, any new database will use RAM only. To create a Redis Enterprise database (REDB) that can use flash storage, specify the following in the `redisEnterpriseCluster` section of the REDB custom resource definition:

- `isRof: true` enables Auto Tiering
- `rofRamSize` defines the RAM capacity for the database

Below is an example REDB custom resource:

[code example]

This example defines both `memorySize` and `rofRamSize`. When using Auto Tiering, `memorySize` refers to the total combined memory size (RAM + flash) allocated for the database. `rofRamSize` specifies only the RAM capacity for the database. `rofRamSize` must be at least 10% of `memorySize`.

code:
apiVersion: app.redislabs.com/v1
kind: RedisEnterpriseCluster
metadata:
  name: "rec"
spec:

  nodes: 3
  redisOnFlashSpec:
    enabled: true
    bigStoreDriver: speedb
    storageClassName: local-scsi
    flashDiskSize: 100G

section_id: create-a-redis-enterprise-cluster

code:
apiVersion: app.redislabs.com/v1alpha1
kind: RedisEnterpriseDatabase
metadata:
  name: autoteiring-redb
spec:
  redisEnterpriseCluster:
    name: rec
  isRof: true
  memorySize: 2GB
  rofRamSize: 0.5GB

section_id: create-a-redis-enterprise-database


title: Get started with Flex on Kubernetes

summary: Configure Flex on your Redis Enterprise cluster for Kubernetes.

title: Overview

text:
This page applies to Redis database version 7.4 and earlier using Auto Tiering. If you use version 8.0 or later, see [Redis Flex](https://redis.io/docs/latest/operate/kubernetes/flex/).

Flex extends your database capacity by combining RAM and flash (SSD) storage. This tiered architecture keeps frequently accessed (hot) data in RAM for sub-millisecond latency while storing less active (warm) data on flash to reduce costs and increase capacity.

title: Prerequisites

text:
Before you begin, verify that you have:

- Redis Enterprise for Kubernetes version 8.0.2-2 or later installed
- A running `RedisEnterpriseCluster` (REC) resource
- Redis database version 7.4 or later
- Locally attached NVMe SSDs on your worker nodes
- A StorageClass configured for flash storage with a unique name

For hardware requirements and sizing guidelines, see [Plan your deployment]().

title: Configure the REC for Flex

text:
To enable Flex, configure your `RedisEnterpriseCluster` (REC) resource with flash storage settings. Add the [`redisOnFlashSpec`]() section to your REC specification.

Key fields in `redisOnFlashSpec`:

| Field                   | Description                                      |
|-------------------------|--------------------------------------------------|
| `enabled`               | Set to `true` to enable Flex.                    |
| `flashStorageClassName` | Name of the StorageClass for flash storage.      |
| `flashDiskSize`         | Size of the flash storage per node.              |
| `storageEngine`         | Storage engine. Set to `speedb` for Flex.        |

For all available fields, see the [REC API reference]().

PVC expansion is not supported when using Flex. Do not enable `enablePersistentVolumeResize` in the REC `persistentSpec` if you are using `redisOnFlashSpec` as this will result in conflicts.

1. Create a REC specification file with flash storage settings similar to the following example:

    [code example]

1. Apply the REC configuration:

    [code example]

1. Verify that the cluster is ready:

    [code example]

title: Create a Flex database

text:
After you configure the cluster, create a `RedisEnterpriseDatabase` (REDB) resource with Flex enabled.

Key fields in the REDB:

| Field        | Description                                            |
|--------------|--------------------------------------------------------|
| `memorySize` | Total database size (RAM + flash).                     |
| `isRof`      | Set to `true` to enable Flex for this database.        |
| `rofRamSize` | Amount of RAM allocated to the database.               |

For all available fields, see the [REDB API reference]().

1. Create a database specification file with `isRof` set to `true` similar to the following example:

    [code example]

1. Apply the REDB:

    [code example]

1. Verify the database status:

    [code example]

title: Verify Flex is active

text:
To confirm that Flex is working:

1. Check the database status:

    [code example]

2. Look for `isRof: true` in the status section.

3. Connect to the database and verify that data operations work correctly.

title: Next steps

text:
- [Scale your deployment](): Learn how to scale volume, throughput, and infrastructure.
- [Plan your deployment](): Review sizing guidelines and best practices.

code:
apiVersion: app.redislabs.com/v1
    kind: RedisEnterpriseCluster
    metadata:
      name: rec
    spec:
      nodes: 3
      redisOnFlashSpec:
        enabled: true
        flashStorageClassName: local-flash
        flashDiskSize: 100Gi
        storageEngine: speedb

section_id: configure-the-rec-for-flex

code: kubectl apply -f rec.yaml

code:
apiVersion: app.redislabs.com/v1alpha1
    kind: RedisEnterpriseDatabase
    metadata:
      name: flex-db
    spec:
      memorySize: 10Gi
      isRof: true
      rofRamSize: 2Gi

section_id: create-a-flex-database

code: kubectl apply -f redb.yaml

code: kubectl get redb

code: kubectl get redb <database-name> -o yaml

section_id: verify-flex-is-active


title: Flex on Kubernetes

summary: Extend Redis databases with flash storage for large-scale, cost-efficient deployments on Kubernetes.

summary: Hardware requirements, sizing guidelines, and limitations for Redis Flex on Kubernetes.

title: Plan a Redis Flex deployment on Kubernetes

title: Get started with Flex on Kubernetes

summary: Scaling strategies and methods for Redis Flex deployments on Kubernetes.

title: Scale Redis Flex on Kubernetes

title: Use Auto Tiering on Kubernetes

title: Overview

text:
Flex extends your database capacity by combining RAM and flash (SSD) storage. This tiered architecture keeps frequently accessed (hot) data in RAM for sub-millisecond latency while storing less active (warm) data on flash to reduce costs and increase capacity.

Flex databases work with your existing Redis applications and the Redis API without modification.

title: How Flex works

title: Automatic data tiering

text:
Flex moves data between RAM and flash based on access patterns:

- Frequently accessed data stays in high-speed RAM.
- Less active data moves to cost-efficient flash storage.
- Data accessed from flash promotes back to RAM automatically.

Redis uses an [LRU (least recently used)]() eviction policy to manage data placement. When memory pressure increases, Flex identifies cold objects, transfers them to flash, and frees RAM for new or frequently accessed keys.

This process requires no application changes. Your existing Redis commands work across both storage tiers.

title: Utilization-aware RAM population

text:
Flex uses a hybrid memory model that balances performance with predictable behavior as the dataset grows. The goal is to maximize hot data in RAM while maintaining stable performance across all utilization levels.

Flex considers both the configured RAM percentage and current dataset utilization:

- When database utilization is below 50%, Flex uses up to 50% of configured RAM for hot data.
- Above 50% utilization, Flex uses both RAM and flash proportionally, following the configured RAM-to-flash ratio.

This ensures:

- A stable performance curve across all utilization levels
- No sudden drop-off in RAM hit-rate as the database fills
- Predictable throughput and latency, especially for large deployments

title: Storage engine

text:
Flex uses [Speedb](https://docs.speedb.io), a high-performance key-value storage engine optimized for flash drives:

- Redis handles all data operations in memory.
- Speedb manages the flash storage layer.

This design delivers predictable latency and throughput as datasets grow beyond RAM limits.

title: Compatibility

text:
Flex is compatible with the Redis API and supports all Redis data types, including JSON and probabilistic data structures (Bloom filters, Count-Min Sketch, Top-K).

The following features are not yet supported with Flex:

- Redis Query Engine (RQE)
- Time series
- Active-Active

title: When to use Flex

text:
Use Flex when you need to:

- Run Redis at terabyte scale while maintaining high throughput and sub-10 ms latency
- Power real-time feature stores for machine learning applications
- Operate large distributed caches with elastic scaling and consistent performance under heavy load
- Reduce infrastructure costs by combining high-speed RAM with cost-efficient flash storage

Flex does not replace long-term data persistence. For workloads that require durability and recovery across restarts or failures, use Redis persistence features like [AOF (Append-Only File)](), [RDB snapshots](), or both. For more information, see [Database persistence]().

title: Flex and Auto Tiering

text:
Flex replaces [Auto Tiering]() (formerly known as Redis on Flash). Redis Enterprise selects the implementation based on your database version:

| Redis database version | Operator version | Redis Flex | Auto Tiering |
|------------------------|------------------|------------|--------------|
| 8.0 and later | 8.0.2-2 and later | ✅ | ❌ |
| 7.4 | 7.8.2-6 and later | ✅ | ✅ |
| 7.2 and earlier | 7.22.2-22 and earlier | ❌ | ✅ |

For Redis Enterprise for Kubernetes version 7.22.2-22 or earlier, see [Auto Tiering]().

title: Differences between Flex and Auto Tiering

text:
- Key and value offloading
  - Auto Tiering offloads only values to flash while keys remain in RAM.
  - Flex offloads both keys and values, which increases dataset density per node and reduces RAM consumption.
- RAM requirements
  - Auto Tiering requires enough RAM to hold all keys.
  - Flex has no requirement to keep keys in RAM. Minimum RAM is based on performance goals, not key count. The minimum RAM-to-flash ratio is 10%, which enables high flash utilization without compromising architecture.
- RAM population strategy
  - Auto Tiering fills all available RAM before offloading data to flash. This maximizes hot-data performance but can cause non-linear performance changes at high utilization.
  - Flex uses utilization-aware RAM population.
- Storage engine
  - Auto Tiering uses either RocksDB or Speedb as the storage engine.
  - Flex uses Speedb only.
- Hot data caching and dataset size
  - Auto Tiering is limited by key memory overhead, which restricts maximum dataset size.
  - Flex is more efficient because RAM holds hot keys and values, supporting larger datasets.
- Performance consistency
  - Auto Tiering depends on RAM pressure and key count.
  - Flex provides higher RAM hit-rate and more stable latency.

title: Next steps

text:
- [Plan your deployment](): Review hardware requirements, sizing guidelines, and limitations.
- [Get started](): Configure Flex on your cluster.
- [Scale your deployment](): Learn scaling strategies and best practices.


title: Overview

text: Review the hardware requirements, sizing guidelines, and known limitations before you deploy Redis Flex.

title: Version requirements

text:
Redis Flex requires:

- Redis Enterprise for Kubernetes version 8.0.2-2 or later
- Redis database version 8.2 or later

title: Hardware requirements

title: Flash storage requirements

text:
Your SSDs must meet these requirements:

- **Locally attached** to worker nodes in your Kubernetes cluster. Network-attached storage (NAS), storage area networks (SAN), and cloud block storage (like AWS EBS) are not supported.
- **Dedicated** to Redis Flex. Don't share Flash storage with other database components like durability, binaries, or persistence.
- **Formatted and mounted** on the nodes that run Redis Enterprise pods.
- **Provisioned as local persistent volumes**. You can use a [local volume provisioner](https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner) for dynamic provisioning.
- **Configured with a StorageClass** resource with a unique name.

For more information about storage configuration, see [Kubernetes local volumes](https://kubernetes.io/docs/concepts/storage/volumes/#local).

title: Flash capacity sizing

text:
Provision Flash capacity that exceeds your total database size. The extra space accounts for:

- Write buffers
- Space amplification
- Operational overhead

title: Recommended SSD types

text:
For best performance, use NVMe SSDs:

| SSD type              | Recommendation                 |
|-----------------------|--------------------------------|
| NVMe Gen 5 or Gen 4   | Recommended                    |
| NVMe Gen 3            | Supported (lower performance)  |

title: Sizing guidelines

title: Shard fundamentals

text: Redis Flex databases consist of shards—independent data partitions that handle a portion of the dataset and request load. Each shard runs as a self-contained Redis process with dedicated memory, CPU, and Flash resources.

title: Recommended shard size

text:
Use these standard building blocks for capacity planning:

- **50 GB per shard**: Standard capacity unit
- **1 vCPU per shard**: Baseline compute allocation

For example, a 1 TB dataset requires 20 shards (20 × 50 GB).

title: RAM-to-flash ratio

text:
The RAM-to-flash ratio directly affects throughput and latency:

- More RAM: Higher throughput and lower latency
- Less RAM: Lower throughput, higher latency, and lower cost

title: Module compatibility

title: Supported

text:
Redis Flex supports:

- All standard Redis data types
- Redis JSON
- Redis probabilistic data structures (Bloom filters, Count-Min Sketch, Top-K)

title: Not supported

text:
Redis Flex doesn't support:

- Redis Query Engine (RQE)
- RedisTimeSeries
- Active-Active databases

title: Best practices

text:
- Store small keys and values (under 10 KB) when possible. Large objects reduce performance, and objects larger than 4 GB can't be stored in Flash.
- Enable replication before populating the database with data. If you enable replication after the database is created, recovery can fail because required persistence files might be missing.
- Increase RAM percentage if 99th-percentile latency exceeds your target or cache hit rates drop.
- Decrease RAM percentage if memory utilization is high but latency remains stable to lower cost and improve efficiency.
- Re-evaluate the ratio of RAM to Flash periodically as dataset size and access patterns evolve.

title: Known limitations

text:
- **Flash storage**: Must be locally attached. Network storage isn't supported.
- **Active-Active**: Not supported with Flex.
- **PVC expansion**: Not supported with `redisOnFlashSpec`. Don't enable `enablePersistentVolumeResize` in the REC `persistentSpec`.
- **Maximum object size**: Keys or values larger than 4 GB remain in RAM only.

Avoid Flex in the following situations:

- Your working set is significantly smaller than the total dataset and access is biased toward recent data (high RAM hit rate).
- Your workload uses very long key names, broad or random access patterns, or a very large working set. These patterns reduce Flex benefits and increase flash I/O.

title: Deprecated fields

text: The `flashStorageEngine` field is deprecated. Use `bigStoreDriver` instead.

title: Next steps

text:
- [Get started](): Configure Redis Flex on your cluster.
- [Scale your deployment](): Learn scaling strategies.


title: Scale Redis Flex on Kubernetes

title: Overview

text: This guide shows you how to scale Flex databases on Kubernetes to meet changing workload demands.

title: Choose a scaling strategy

text:
Use the following table to determine the best scaling strategy for your Flex deployment:

| Goal | Recommended action |
|------|--------------------|
| Increase data capacity only without adding CPU | [Increase `memorySize` and decrease RAM percentage](#decrease-ram-to-flash-ratio) |
| Increase throughput only | [Add shards and vCPU](#add-shards-or-nodes) |
| Increase data capacity and throughput | [Add shards](#add-shards) |
| Improve latency under higher load | [Increase RAM percentage](#increase-ram-to-flash-ratio) |
| Reduce cost while maintaining performance | [Tune RAM-to-flash ratio](#decrease-ram-to-flash-ratio) |

title: Prerequisites

text: Before you scale a Flex deployment, verify that your cluster has sufficient resources, such as memory, disk, and vCPU.

title: Scale volume

text:
If your dataset requires more capacity while maintaining performance, you can prepare a Flex database to store more data using one of the following options:

1. Increase `memorySize` and [add shards](#add-shards).

1. Increase `memorySize` and [decrease the RAM-to-flash ratio](#decrease-ram-to-flash-ratio).

title: Add shards

text:
You can add more shards to expand dataset capacity while maintaining the existing RAM-to-flash ratio. Throughput capacity also typically increases as a result of additional shards and infrastructure. This strategy is recommended when the dataset size and traffic are expected to grow together.

Before you increase the dataset capacity and add shards, you need to add more RAM and vCPUs to handle the increased number of shards.

To increase the dataset capacity and shards:

1. Edit your REDB custom resource:

    [code example]

1. Increase `memorySize` in the `spec` section.

1. Increase `shardCount` in the `spec` section.

1. Save and close the file.

title: Decrease RAM-to-flash ratio

text:
You can allocate more data to the flash tier to increase the database capacity while keeping the same amount of RAM, shards, and vCPU. This strategy is recommended when scaling for volume only and SSD resources are underutilized. This increases capacity without adding CPU or RAM but can lower RAM hit-rate and increase p99 latency; monitor metrics before and after the change.

To increase the dataset capacity and decrease the RAM-to-flash ratio:

1. Edit your REDB custom resource:

    [code example]

1. Increase `memorySize` in the `spec` section.

1. Decrease `rofRamSize` in the `redisOnFlashSpec` section.

1. Save and close the file.

title: Scale throughput

text:
If your workload's read/write rate increases and latency starts to rise, you can prepare the database to handle more traffic using one of the following strategies:

1. [Add shards or nodes](#add-shards-or-nodes).

1. [Increase the RAM-to-flash ratio](#increase-ram-to-flash-ratio).

title: Add shards or nodes

text:
You can add more shards or nodes to distribute traffic and increase throughput without changing the RAM-to-flash ratio. Dataset size capacity also typically increases as a result of additional shards and infrastructure. This strategy is recommended when the dataset size and traffic are expected to grow together.

Before you add shards or nodes, you need to add more RAM and vCPUs to handle the increased number of shards or nodes. This increases capacity and potential throughput but requires more RAM, vCPUs, and a rebalance operation.

To add shards:

1. Edit your REDB custom resource:

    [code example]

1. Increase `shardCount` in the `spec` section.

1. Save and close the file.

To add nodes to the cluster, increase the `nodes` count in your RedisEnterpriseCluster (REC) custom resource:

[code example]

title: Increase RAM-to-flash ratio

text:
To improve throughput and lower latency, you can expand the in-memory tier to serve a higher proportion of requests directly from RAM. This strategy is recommended when low latency is your primary goal and you don't need to increase the dataset size.

Before increasing the RAM-to-flash ratio, you might need to add more nodes to accommodate additional RAM. This improves throughput and lowers latency by serving more requests from RAM, at the cost of higher RAM usage.

To increase the RAM-to-flash ratio:

1. Edit your REDB custom resource:

    [code example]

1. Increase `rofRamSize` in the `redisOnFlashSpec` section.

1. Save and close the file.

title: Scale infrastructure

text:
You can increase or adjust the underlying resources supporting the database, such as CPU, memory, and disk.

For Flex deployments on Kubernetes, ensure the cluster has sufficient physical resources before scaling. The cluster requires:

- Enough RAM to support the desired in-memory dataset size.

- Enough SSD capacity for flash-tier data.

- Adequate vCPU to support increased shard count or throughput.

Scaling operations will fail or underperform if the underlying cluster is resource-constrained.

PVC expansion is not supported with `redisOnFlashSpec`. Plan flash storage capacity upfront and don't enable `enablePersistentVolumeResize` in the REC `persistentSpec`.

See Flex [hardware requirements]() for more information.

code: kubectl edit redb <database-name>

section_id: add-shards

section_id: decrease-ram-to-flash-ratio

section_id: add-shards-or-nodes

code: kubectl edit rec <cluster-name>

section_id: increase-ram-to-flash-ratio


title: Redis Enterprise for Kubernetes

summary: Deploy and manage Redis Enterprise on Kubernetes with the Redis Enterprise operator.

summary: Overview of the architecture and components of Redis Enterprise for Kubernetes.

title: Redis Enterprise for Kubernetes architecture

title: Deployment

summary: Upgrade Redis Enterprise operator, clusters, and databases on Kubernetes.

title: Upgrade Redis Enterprise for Kubernetes

summary: Create and manage Redis Enterprise clusters (REC) on Kubernetes using the Redis Enterprise operator.

title: Redis Enterprise clusters (REC)

summary: Create and manage Redis Enterprise databases (REDB) on Kubernetes using the Redis Enterprise operator.

title: Redis Enterprise databases (REDB)

summary: Create and manage Active-Active Redis Enterprise databases across multiple Kubernetes clusters.

title: Active-Active databases

summary: Configure networking and external access for Redis Enterprise clusters and databases on Kubernetes.

title: Networking

title: Flex on Kubernetes

summary: Configure security settings for Redis Enterprise clusters and databases on Kubernetes.

title: Security

summary: Access and manage Redis Enterprise logs on Kubernetes for monitoring and troubleshooting.

title: Logs

summary: Best practices and configuration recommendations for Redis Enterprise on Kubernetes deployments.

title: Configuration recommendations

summary: Resources to help you manage Redis Enterprise custom resources on Kubernetes.

title: Reference

summary: Redis Enterprise Software for Kubernetes operator release notes.

title: Redis Enterprise Software for Kubernetes release notes

summary: Describes where to view the archive of Redis Enterprise for Kubernetes documentation.

title: Archive

title: Overview

text:
Redis Enterprise for Kubernetes brings Redis Enterprise to Kubernetes environments through the Redis Enterprise operator. You can deploy, scale, and manage Redis Enterprise clusters and databases by using native Kubernetes resources and workflows.

Redis Enterprise for Kubernetes provides all the enterprise features of Redis Software:

- Linear scalability with Redis clustering
- High availability with automatic failover
- Active-Active geo-distribution
- Redis Flex for cost optimization
- Enterprise-grade security and encryption
- 24/7 support

The Redis Enterprise operator simplifies deployment and management by providing custom resource definitions (CRDs) for Redis Enterprise clusters (REC) and databases (REDB). This approach enables GitOps workflows and Kubernetes-native operations.

title: Get started

text:
Deploy Redis Enterprise on your Kubernetes cluster and create your first database.

- [Quick start deployment]()
- [Deploy with Helm]()
- [Deploy on OpenShift]()
- [Supported Kubernetes distributions]()

title: Redis Enterprise clusters (REC)

text:
Create and manage [Redis Enterprise clusters]() on Kubernetes.

- [Connect to admin console]()
- [Redis Flex]()
- [Multi-namespace deployment]()
- [Cluster recovery]()
- [REC API reference]()

title: Redis Enterprise databases (REDB)

text:
Create and manage [Redis Enterprise databases]() using Kubernetes resources.

- [Database controller]()
- [Create replica databases]()
- [REDB API reference]()

title: Active-Active databases

text:
Set up globally distributed [Active-Active databases]() across multiple Kubernetes clusters.

- [Prepare participating clusters]()
- [Create Active-Active database]()
- [Global configuration]()
- [REAADB API reference]()
- [Remote cluster API reference]()

title: Security

text:
Manage [secure connections]() and access control for your Redis Enterprise deployment.

- [Manage REC credentials]()
- [Manage REC certificates]()
- [Internode encryption]()
- [LDAP authentication]()

title: Reference

role: related

text:
Use the Kubernetes API and command-line tools to manage your Redis Enterprise deployment.

- [Redis Enterprise cluster API (REC)]()
- [Redis Enterprise database API (REDB)]()
- [Active-Active database API (REAADB)]()
- [Remote cluster API (RERC)]()

title: Logs & monitoring

text:
Monitor and troubleshoot your Redis Enterprise deployment.

- [Collect logs]()
- [Connect to Prometheus operator]()

title: Upgrade

text:
Keep your Redis Enterprise deployment up to date.

- [Upgrade Redis cluster]()
- [Upgrade with OpenShift CLI]()
- [Upgrade with OLM]()

title: Release notes

text:
Stay informed about new features, enhancements, and fixes.

- [Release notes]()

title: Related info

text:
- [Redis Enterprise Software]()
- [Redis Cloud]()
- [Redis Open Source]()
- [Glossary]()


title: Archive

title: Content

text:
The Redis Enterprise for Kubernetes documentation is versioned. You are looking at the documentation for the latest release.

- View the [7.8.6 docs](https://redis.io/docs/latest/operate/kubernetes/7.8.6/) for Redis Enterprise for Kubernetes version 7.8.6-1.
- View the [7.8.4 docs](https://redis.io/docs/latest/operate/kubernetes/7.8.4/) for Redis Enterprise for Kubernetes versions 7.8.2-6, 7.8.4-8, and 7.8.4-9.
- View the [7.4.6 docs](https://redis.io/docs/latest/operate/kubernetes/7.4.6/) for Redis Enterprise for Kubernetes versions 7.4.6-2 and 7.4.6-6.

Older versions of Redis Enterprise for Kubernetes documentation are available on the archived web site:

- [Redis Enterprise for Kubernetes v7.4 documentation archive](https://docs.redis.com/7.4/kubernetes/)

- [Redis Enterprise for Kubernetes v7.2 documentation archive](https://docs.redis.com/7.2/kubernetes/)

- [Redis Enterprise for Kubernetes v6.x documentation archive](https://docs.redis.com/6.4/kubernetes/)


title: Collect logs

summary: Run the log collector script to package relevant logs into a tar.gz file to send to Redis Support for help troubleshooting your Kubernetes environment.

title: Overview

text:
The Redis Enterprise cluster (REC) log collector script ([`log_collector.py`](https://github.com/RedisLabs/redis-enterprise-k8s-docs/blob/master/log_collector/log_collector.py)) creates and fills a directory with the relevant logs for your environment. These logs will help the support team with troubleshooting.

The log collector tool has two modes:

- **restricted** collects only resources and logs created by the operator and Redis Enterprise deployments
- **all** collects everything from your environment

 This script requires Python 3.11 or later.

title: Prerequisites

text: Before running the log collector, ensure you have the appropriate RBAC permissions configured. See [Log collector RBAC examples]() for detailed RBAC configuration instructions.

title: Collect logs

text:
1. Download the latest [`log_collector.py`](https://github.com/RedisLabs/redis-enterprise-k8s-docs/blob/master/log_collector/log_collector.py) file.

1. Ensure your `kubectl` or `oc` CLI is configured to access the Kubernetes cluster you want to collect logs from.

1. Have a K8s administrator run the script on the system that runs your `kubectl` or `oc` commands.

    [code example]

title: Options

role: parameters

text:
You can run `log_collector.py` with the following options:

| Option | Description |
|--------|-------------|
| `-n`, `--namespace` | Sets the namespace(s) to collect from. Can be set to a single namespace, or multiple namespaces (comma-separated). When left empty, will use the current context's namespace from kubeconfig. |
| `-o`, `--output_dir` | Sets the output directory. Defaults to current working directory. |
| `-a`, `--logs_from_all_pods` | Collect logs from all pods in the selected namespace(s), and otherwise collect only from the operator and pods run by the operator. |
| `-t`, `--timeout` | Time to wait for external commands to finish execution (Linux only). Defaults to 180s. Specify 0 to disable timeout. |
| `--k8s_cli` | The K8s cli client to use (kubectl/oc/auto-detect). Defaults to auto-detect (chooses between 'kubectl' and 'oc'). Full paths can also be used. |
| `-m`, `--mode` | Controls which resources are collected. In 'restricted' mode, only resources associated with the operator and have the label 'app=redis-enterprise' are collected. In 'all' mode, all resources are collected. Defaults to 'restricted' mode. |
| `--collect_istio` | Collect data from istio-system namespace to debug potential problems related to istio ingress method. |
| `--collect_empty_files` | Collect empty log files for missing resources. |
| `--helm_release_name` | Collect resources related to the given Helm release name. |
| `--collect_rbac_resources` | Temporary development flag. Collect all role based access control related custom resources. |
| `-h`, `--help` | Show help message and exit. |

 If you get an error because the yaml module is not found, install the pyYAML module with `pip install pyyaml`.

1. Upload the resulting `tar.gz` file containing all the logs to [Redis Support](https://support.redislabs.com/).

code: python log_collector.py

section_id: collect-logs


title: Logs

title: Collect logs

title: Overview

text: Access and manage Redis Enterprise logs on Kubernetes for monitoring, troubleshooting, and debugging your Redis Enterprise deployment. Logs provide valuable insights into cluster operations, database performance, and system health.

title: Log collection and access

text:
Learn how to collect and access logs from your Redis Enterprise deployment:

- [Collect logs]() - Methods for collecting logs from Redis Enterprise pods and containers

title: Log storage and access

text:
Each Redis Enterprise container stores its logs under `/var/opt/redislabs/log`. When using persistent storage, this path is automatically mounted to the `redis-enterprise-storage` volume, making logs accessible through sidecar containers or external log collection tools.

For example, in the REC (Redis Enterprise Cluster) spec you can add a sidecar container, such as a busybox, and mount the logs to there:

[code example]

Now the logs can be accessed from in the sidecar. For example by running

```kubectl exec -it <pod-name> -c busybox -- tail home/logs/supervisord.log```

The sidecar container is user determined and can be used to format, process and share logs in a specified format and protocol.

code:
sideContainersSpec:
  - name: busybox
    image: busybox
    args:
      - /bin/sh
      - -c
      - while true; do echo "hello"; sleep 1; done

    volumeMounts:
    - name: redis-enterprise-storage
      mountPath: /home/logs
      subPath: logs

section_id: log-storage-and-access


title: Enable cluster-aware clients (OSS Cluster API)

summary: Improve performance with cluster-aware clients by enabling the OSS Cluster API for your Redis Enterprise for Kubernetes database.

title: Overview

text:
The OSS Cluster API improves performance by allowing cluster-aware Redis clients to discover database topology and route requests directly. This feature supports cluster-aware clients running on the same Kubernetes cluster (internal) and cluster-aware clients outside the Kubernetes cluster (external).

Enabling external access for OSS Cluster API creates a separate LoadBalancer service for each Redis Enterprise pod in addition to the LoadBalancer service for the cluster endpoint. LoadBalancers are resources that can significantly increase operational costs; plan your infrastructure budget accordingly.

title: Prerequisites

text:
- RedisEnterpriseCluster (REC) running version 8.0.10-tbd or later.
- Proxy policy is set to `all-master-shards` or `all-nodes`.
- Modules used by the database (if any) are bundled modules.
- The database is not an Active-Active database.

title: Limitations

text: - OSS Cluster databases with external access must be created and managed using the RedisEnterpriseDatabase (REDB) custom resource. You cannot create or configure these databases using the Redis Enterprise REST API directly.

title: Enable OSS Cluster API

text: To enable cluster-aware clients, edit the REC and REDB custom resources with the following fields.

title: Edit REC (RedisEnterpriseCluster) {#edit-rec}

text:
1. Edit the RedisEnterpriseCluster (REC) custom resource to add the `ossClusterSettings` section to the `spec` section.

Set `externalAccessType` to `LoadBalancer` and add any `serviceAnnotations`, if required by your service provider.

[code example]

2. If you are using internal clients (within the Kubernetes cluster), you can specify their IP ranges in the `podCIDRs` field to improve performance. Clients from these ranges are routed directly to the Redis Enterprise pods, without going through the load balancer.

The following is an example `podCIDRs` field using example values; replace with your own unique CIDRs.

[code example]

title: Edit REDB (RedisEnterpriseDatabase) {#edit-redb}

text:
3. Edit the REDB custom resource to add the following fields and values to the `spec` section.

Set `enableExternalAccess: true` to allow external clients to connect. This provisions a LoadBalancer service for each Redis Enterprise pod running a node, which increases infrastructure costs.

[code example]

title: Connect clients

text:
Use the `kubectl get svc` command to view the services created by the OSS Cluster API. It should look similar to this example:

[code example]

To connect an external client (outside the Kubernetes cluster), use the `EXTERNAL-IP` address for the `oss-cluster-load-balancer` service.

To connect an internal client (listed in the `podCIDRs` field), use the `CLUSTER-IP` address for the `oss-cluster` service.

code:
ossClusterSettings:
    externalAccessType: LoadBalancer
    loadBalancer:
      serviceAnnotations:

code:
ossCluster: true

  ossClusterSettings:
    enableExternalAccess: true

code:
NAME                           TYPE           CLUSTER-IP       EXTERNAL-IP      PORT(S)              AGE
admission                      ClusterIP      10.0.1.10        <none>           443/TCP              3h28m
oss-cluster                    ClusterIP      10.0.1.20        <none>           11712/TCP            3h6m
oss-cluster-headless           ClusterIP      None             <none>           11712/TCP            3h6m
oss-cluster-load-balancer      LoadBalancer   10.0.1.30        203.0.113.10     11712:30245/TCP      3h6m
rec                            ClusterIP      10.0.1.40        <none>           9443/TCP,8001/TCP    3h27m
rec-cluster                    LoadBalancer   10.0.1.50        203.0.113.20     11712:32559/TCP      3h6m
rec-1-lb                       LoadBalancer   10.0.1.60        203.0.113.30     11712:31976/TCP      3h6m
rec-2-lb                       LoadBalancer   10.0.1.70        203.0.113.40     11712:31972/TCP      3h6m
rec-oss                        ClusterIP      None             <none>           8070/TCP             3h27m
rec-ui                         ClusterIP      10.0.1.80        <none>           8443/TCP             3h27m

section_id: connect-clients


title: Database connectivity

summary: Connect applications to Redis Enterprise databases in Kubernetes clusters with in-cluster and external access patterns.

title: Overview

text: Connecting applications to Redis Enterprise databases in Kubernetes involves understanding service discovery, credentials management, and access patterns. This guide covers the essential connectivity aspects unique to Kubernetes deployments.

title: Service types and access patterns

text: When you create a RedisEnterpriseDatabase (REDB), the Redis Enterprise operator automatically creates Kubernetes services to route traffic to your database. Understanding these service types is crucial for proper connectivity.

title: Default service creation

text:
By default, the operator creates two services for each database:

- ClusterIP service - Provides a stable cluster-internal IP address.
- Headless service - Enables direct pod-to-pod communication and service discovery.

Both services are created in the same namespace as your database and follow predictable naming conventions.

title: Service types

text:
Redis Enterprise supports three service types for database access:

| Service Type | Rigger Spec Exact Name | Access Scope | Use Case |
|--------------|--------------|--------------|----------|
| `ClusterIP` | `cluster_ip` | Cluster-internal only | Applications running within the same Kubernetes cluster |
| `headless` | `headless` | Cluster-internal only | Direct pod access, service discovery, StatefulSet scenarios |
| `LoadBalancer` | `load_balancer` | External access | Applications outside the Kubernetes cluster |

To configure the service type, use the `databaseServiceType` field in your REC's `servicesRiggerSpec`.

For example, to enable the three Service options, you may use:
[code example]

title: In-cluster database access

text: For applications running within your Kubernetes cluster, use the automatically created services to connect to your databases.

title: Retrieve connection information

text:
Database connection details are stored in a Kubernetes secret maintained by the database controller. This secret contains:

- Database port (`port`)
- Service names (`service_names`)
- Database password (`password`)

1. Get the secret name from your database resource:

   [code example]

   The secret name typically follows the pattern `redb-<database-name>`.

2. Retrieve the database port:

   [code example]

3. Get available service names:

   [code example]

4. Retrieve the database password:

   [code example]

title: Service naming and DNS resolution

text:
Services follow standard Kubernetes DNS naming conventions:

- Service FQDN: `<service-name>.<namespace>.svc.cluster.local`
- Short name: `<service-name>` (within the same namespace)

For a database named `mydb` in namespace `production`, the service names would be:
- ClusterIP service: `mydb.production.svc.cluster.local`
- Headless service: `mydb-headless.production.svc.cluster.local`

title: Connect from within the cluster

text:
Use any service name from the `service_names` list to connect:

[code example]

Then authenticate with the retrieved password:

[code example]

title: External database access

text: To access databases from outside the Kubernetes cluster, you need to configure external routing. Currently supported methods for external access are ingress controllers or OpenShift routes.

title: Ingress controllers

text:
Redis Enterprise for Kubernetes only supports the following ingress controllers for external database access:

- NGINX Ingress - Supports SSL passthrough for Redis connections
- HAProxy Ingress - Built-in SSL passthrough support
- Istio Gateway - Service mesh integration with advanced traffic management

See [Ingress routing]() for detailed configuration steps.

title: OpenShift routes

text:
OpenShift users can leverage routes for external access:

[code example]

See [OpenShift routes]() for complete setup instructions.

title: Service ports and configuration

title: Default port behavior

text:
- Redis Enterprise databases use dynamic port allocation.
- Port numbers are assigned automatically during database creation.
- The actual port is stored in the database secret.

title: Custom port configuration

text:
You can specify custom ports using the `databasePort` field in your REDB specification:

[code example]

Custom ports replace the default service port and are reflected in the database secret.

title: Credentials and secrets management

title: Database secrets structure

text:
Each database has an associated Kubernetes secret containing connection details:

[code example]

title: Using secrets in applications

text:
Reference database secrets in your application deployments:

[code example]

title: Default user configuration

text:
By default, databases create a default user with full access. You can disable this behavior:

[code example]

When `defaultUser` is disabled, the database secret is not created, and you must configure custom authentication.

title: Connection examples

title: Python application

text: [code example]

title: Node.js application

text: [code example]

title: Troubleshooting connectivity

role: errors

title: Common issues

text:
1. Connection refused - Verify service names and ports from the database secret.
2. Authentication failed - Check password encoding and special characters.
3. DNS resolution - Ensure applications use correct service FQDNs.
4. Network policies - Verify Kubernetes network policies allow traffic.

title: Debugging steps

text:
1. Verify service creation:
   [code example]

2. Check service endpoints:
   [code example]

3. Test connectivity from within cluster:
   [code example]

title: Related topics

text:
- [Ingress routing]() - Configure external access with ingress controllers
- [OpenShift routes]() - External access using OpenShift routes
- [Database controller]() - Database lifecycle management
- [Security]() - TLS configuration and access control

section_id: service-types

code: kubectl get redb <database-name> -o jsonpath="{.spec.databaseSecretName}"

section_id: retrieve-connection-information

code: kubectl get secret redb-<database-name> -o jsonpath="{.data.port}" | base64 --decode

code: kubectl get secret redb-<database-name> -o jsonpath="{.data.service_names}" | base64 --decode

code: kubectl get secret redb-<database-name> -o jsonpath="{.data.password}" | base64 --decode

code: redis-cli -h <service-name> -p <port>

section_id: connect-from-within-the-cluster

code: auth <password>

code:
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: redis-route
spec:
  to:
    kind: Service
    name: <database-service-name>
  port:
    targetPort: redis
  tls:
    termination: passthrough

section_id: openshift-routes

code:
apiVersion: app.redislabs.com/v1alpha1
kind: RedisEnterpriseDatabase
metadata:
  name: mydb
spec:
  memorySize: 256MB
  databasePort: 6379

section_id: custom-port-configuration

code:
apiVersion: v1
kind: Secret
metadata:
  name: redb-<database-name>
type: Opaque
data:
  port: <base64-encoded-port>
  service_names: <base64-encoded-service-list>
  password: <base64-encoded-password>

section_id: database-secrets-structure

code:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  template:
    spec:
      containers:
      - name: app
        image: my-app:latest
        env:
        - name: REDIS_HOST
          value: "<service-name>"
        - name: REDIS_PORT
          valueFrom:
            secretKeyRef:
              name: redb-<database-name>
              key: port
        - name: REDIS_PASSWORD
          valueFrom:
            secretKeyRef:
              name: redb-<database-name>
              key: password

section_id: using-secrets-in-applications

code:
apiVersion: app.redislabs.com/v1alpha1
kind: RedisEnterpriseDatabase
metadata:
  name: mydb
spec:
  memorySize: 256MB
  defaultUser: false

section_id: default-user-configuration

code:
import redis
import base64
import os

# Read from Kubernetes secret (mounted as environment variables)
host = os.getenv('REDIS_HOST')
port = int(os.getenv('REDIS_PORT'))
password = os.getenv('REDIS_PASSWORD')

# Create Redis connection
r = redis.Redis(host=host, port=port, password=password, decode_responses=True)

# Test connection
r.ping()

section_id: python-application

code:
const redis = require('redis');

const client = redis.createClient({
  host: process.env.REDIS_HOST,
  port: process.env.REDIS_PORT,
  password: process.env.REDIS_PASSWORD
});

client.on('connect', () => {
  console.log('Connected to Redis');
});

section_id: node-js-application

code: kubectl get services -l app=redis-enterprise

section_id: debugging-steps

code: kubectl get endpoints <service-name>

code: kubectl run redis-test --image=redis:latest -it --rm -- redis-cli -h <service-name> -p <port>


title: Networking

title: Database connectivity

summary: Configure an ingress controller to access your Redis Enterprise databases from outside the Kubernetes cluster.

title: Configure Ingress for external routing

title: Use OpenShift routes for external database access

summary: Configure Istio as an ingress controller for access to your Redis Enterprise databases from outside the Kubernetes cluster.

title: Configure Istio for external routing

title: Establish external routing on the RedisEnterpriseCluster

title: Overview

text: Configure networking and external access for your Redis Enterprise deployment on Kubernetes. By default, Kubernetes doesn't allow external access to your Redis databases. Redis Enterprise for Kubernetes provides several methods to route external traffic to your clusters and databases.

title: Database connectivity

text:
Connect applications to your Redis Enterprise databases:

- [Database connectivity]() - Comprehensive guide to in-cluster and external database access, service discovery, and credentials management.

title: External routing methods

text:
Choose the appropriate method for your environment to enable external access:

- [Ingress routing]() - Use NGINX or HAProxy ingress controllers with `ingress` API resources
- [Istio ingress routing]() - Use Istio service mesh with `Gateway` and `VirtualService` API resources
- [OpenShift routes]() - Use OpenShift-specific route resources for external traffic

title: Automatic ingress configuration

text:
For Active-Active databases, configure automatic ingress creation:

- [REC external routing]() - Use `ingressOrRouteSpec` field in RedisEnterpriseCluster (REC) for automatic ingress creation

title: `ingressOrRouteSpec` for Active-Active databases

text:
Versions 6.4.2 or later of Redis Enterprise for Kubernetes include a feature for ingress configuration. The `ingressOrRouteSpec` field is available in the RedisEnterpriseCluster spec to automatically create an Ingress (or route) for the API service and databases (REAADB) on that REC. See [REC external routing]() for more details.

This feature only supports automatic Ingress creation for Active-Active databases created and managed with the RedisEnterpriseActiveActiveDatabase (REAADB) custom resource. Use with the standard Redis Enterprise database (REDB) is not currently supported.

title: OSS Cluster API support

text:
[OSS Cluster API]() is supported for both internal and external clients:

- **Internal clients** running on pods within the same Kubernetes cluster can connect directly to Redis Enterprise pods using pod IPs.
- **External clients** outside the Kubernetes cluster can connect through LoadBalancer services when `enableExternalAccess: true` is configured in the database specification. This creates a separate LoadBalancer service for each Redis Enterprise pod. Note that LoadBalancers are resources that can significantly increase operational costs.

See [Enable cluster-aware clients (OSS Cluster API)]() for configuration details.

title: REC domain name

text: The RedisEnterpriseCluster does not support custom domain names. Domain names for the REC are in the following format: `<rec-name>.<namespace>.svc.cluster.local`.