These are the steps required to set up a Redis Enterprise Software Cluster with OpenShift.


  1. An OpenShift cluster installed with at least three nodes (each meeting the minimum requirements for a development installation
  2. The kubectl package installed at version 1.8 or higher
  3. The OpenShift cli installed

Step 1: Login

  • Log in to your OpenShift account as a super admin (so you have access to all the default projects).
  • Create a new project, fill in the name and other details for the project and hit “Create.”


  • Click on “admin” (upper right corner) and then “Copy Login.”


  • Paste the login command into your shell; it should look something like this:

oc login –token=your$login$token

  • Next, verify that you are using the newly created project. Type:
 $ oc login –token=your$login$token

This will shift to your project rather than the default project (you can verify the project you’re currently using with the oc project command).

Step 2: Get deployment files

  • Clone this repository, which contains the deployment files: src $ git clone Note: For RHEL images, please use the redis-enterprise-cluter_rhel.yaml and operator_rhel.yaml files.

Specifically for the redis-enterprise-cluster yaml file, you may also download and edit one of the following examples: simple, persistent, service broker, service broker RHEL (for RHEL images) or use the one provided in the repository.

Step 3: Prepare your yaml files

Let’s look at each yaml file to see what requires editing:

The scc (Security Context Constraint) yaml defines the cluster’s security context constraints, which we will apply to our project later on. We strongly recommend not changing anything in this yaml file.

Apply the file:

 $ oc apply -f scc.yaml

You should receive the following response: “redis-enterprise-scc” configured

Now you need to bind the scc to your project by typing:

 $ oc adm policy add-scc-to-group redis-enterprise-scc  system:serviceaccounts:your_project_name

(If you do not remember your project name, run “oc project”)

The rbac (Role-Based Access Control) yaml defines who can access which resources. We need this to allow our Operator application to deploy and manage the entire Redis Enterprise deployment (all cluster resources within a namespace). Therefore, we strongly recommend not changing anything in this yaml file. To apply it, type:

 $ kubectl apply -f rbac.yaml

You should receive the following response: created serviceaccount/redis-enterprise-operator created created

If you’re deploying a service broker, also apply the sb_rbac.yaml file. The sb_rbac (Service Broker Role-Based Access Control) yaml defines the access permissions of the Redis Enterprise Service Broker.

We strongly recommend not changing anything in this yaml file.

To apply it, run:

 $ kubectl apply -f sb_rbac.yaml

You should receive the following response: configured configured

The next step applies crd.yaml, creating a CustomResourceDefinition for your Redis Enterprise Cluster resource. This provides another API resource to be handled by the k8s API server and managed by the operator we will deploy next. We strongly recommend not changing anything in this yaml file.

To apply it, run:

 $ kubectl apply -f crd.yaml

You should receive the following response: configured

Applying this yaml creates the operator deployment, which is responsible for managing the k8s deployment and lifecycle of a Redis Enterprise Cluster. Among many other responsibilities, it creates a stateful set that runs the Redis Enterprise nodes (as pods).

Always make sure you have the latest operator.yaml. Alternatively, you can edit the following tag: image:redislabs/operator:tag

To apply the operator.yaml, run:

 $ kubectl apply -f operator.yaml

You should receive the following response:

deployment.apps/redis-enterprise-operator created

Now, run kubectl get deployment and verify that your redis-enterprise-operator deployment is running. A Typical response will look like this:


The mycluster yaml defines the configuration of the newly created resource: Redis Enterprise Cluster. This yaml could be renamed your_cluster_name.yaml to keep things tidy, but this isn’t a mandatory step.

This yaml must be edited, however, to reflect the specific configurations of your Cluster. Here are the main fields you should review and edit:

  • name: “your_cluster_name” (e.g. “demo-cluster”)
  • nodes: number_of_nodes_in_the_cluster (Must be an uneven number of at least 3 or greater—here’s why)
  • uiServiceType: service_type

Service type value can be either ClusterIP or LoadBalancer. This is an optional configuration based on k8s service types. The default is ClusterIP.

  • username: <your_email@your_domain.your_suffix>


enabled: <false/true>

Check your Redis Software nodes’ enabled/disabled flag for persistency. The default is “false.”

  • storageClassName: “gp2

This specifies the StorageClass used for your nodes’ persistent disks. This is mandatory when persistence is enabled (for example, AWS uses “gp2” as a default and GKE uses “pd-standard” as a default).

  • redisEnterpriseNodeResources: The compute resources required for each node.
  • limits – specifies the max resources for a Redis node
  • requests – specifies the minimum resources for a Redis node

For example:

limits cpu: “2000m” memory: 4Gi requests

cpu: “2000m” memory: 4Gi

The default (if unspecified) is 2 cores (2000m) and 4GB (4Gi).

  • serviceBrokerSpec –
  • enabled: <false/true>

This specifies persistence for the Service Broker with an “enabled/disabled” flag. The default is “false.”

persistentSpec: storageClassName: “gp2“

  • redisEnterpriseImageSpec: This configuration controls the Redis Enterprise version used, and where it is fetched from. We always recommend running the current GA version.

imagePullPolicy: IfNotPresent Repository: redislabs/redis versionTag: 5.2.0-14–

The version tag, as it appears on your repository (e.g. on DockerHub).

This is an optional configuration. If omitted, it will default to the latest version.

Step 4: Create your Cluster

Once you have your_cluster_name yaml set, you need to apply it to create your Redis Enterprise Cluster:

 $ kubectl apply -f your_cluster_name.yaml

Run kubectl get rec and verify that creation was successful (rec is a shortcut for “RedisEnterpriseClusters”).

You should receive a response similar to the following:


Your_cluster_name 17s

Your Cluster will be ready shortly—typically within a few minutes.

To check the cluster status, type the following:

 $ kubectl get pod

You should receive a response similar to the following:

your_cluster_name-0 1/1 Running 0 1m
your_cluster_name-1 1/1 Running 0 1m
your_cluster_name-2 1/1 Running 0 1m
your_cluster_name-controller-x-x 1/1 Running 0 1m
Redis-enterprise-operator-x-x 1/1 Running 0 5m

Next, create your databases.

Step 5: Create a database

In order to create your database, we will log in to the Redis Enterprise UI.

  • First, apply port forwarding to your Cluster: src $ kubectl port-forward your_cluster_name-0 8443:8443 Note: your_cluster_name-0 is one of your cluster pods. You may consider running the port-forward command in the background.

Note: The Openshift UI provides tools for creating additional routing options, including external routes. These are covered in RedHat Openshift documentation.](

Next, create your database.

  • Open a browser window and navigate to localhost:8443


  • In order to retrieve your password, navigate to the OpenShift management console, select your project name, go to Resources->Secrets->your_cluster_name
  • Retrieve your password by selecting “Reveal Secret.”


Note: In order to conduct the Ping test through Telnet, you can create a new route to the newly created database port in the same way as described above for the UI port. After you create your database, go to the Openshift management console, select your project name and go to Applications->Services. You will see two newly created services representing the database along with their IP and port information, similar to the screenshot below.