FAQs

An Operator is a Kubernetes custom controller which extends the native K8s API. Please refer to the article Redis Enterprise K8s Operator-based deployments – Overview.

The Redis Enterprise Operator may only deploy a single Redis Enterprise Cluster per namespace. Each Redis Enterprise Cluster can run multiple databases while maintaining high capacity and performance.

Yes, one Operator per namespace, each managing a single Redis Enterprise Cluster.

Each Redis Enterprise Cluster can run multiple databases while maintaining high capacity and performance.

Run the following:

kubectl get rec
kubectl describe rec my-cluster-name

The cluster admin user password is created by the Operator during the deployment of the Redis Enterprise cluster and is stored in a Kubernetes secret.

If you must use a different admin password, create an additional user with admin privileges and configure with the new password.

While Helm Charts help automate multi-resource deployments, they do not provide the lifecycle management and lack many of the benefits provided by the Operator:

• Operators are a K8s standards while Helm is a proprietary tool
  • Using Operators means the better packaging for different Kubernetes deployments and distributions as Helm is not supported in a straightforward way everywhere
• Operators allow full control over the Redis Enterprise Cluster lifecycle
  • We’ve experienced difficulties managing state and lifecycle of the application through Helm as it essentially only allows to determine the resources being deployed, which is a problem when upgrading and evolve the Redis Enterprise Cluster settings
• Operators support advanced flows which would otherwise require using an additional 3rd party

Create a port forwarding rule to expose the cluster UI port. For example, when the default port 8443 is used, run:

kubectl port-forward –namespace <namespace> service/<name>-cluster-ui 8443:8443

Connect to the UI by pointing your browser to https://localhost:8443

For nodes hosting the Redis Enterprise Cluster statefulSet pods, please follow the guidelines provided for Redis Enterprise in the hardware requirements.

For additional information please also refer to Kubernetes Operator Deployment – Persistent Volumes.

The Redis Enterprise Cluster stores the username/password of the UI in a K8s secret.

To retrieve, first, find the secret by retrieving secrets and locating one of type Opaque with a name identical or containing your Redis Enterprise Cluster name.

For example, run:

kubectl get secrets

A possible response may look like this:

To retrieve the secret run:

kubectl get secret redis-enterprise-cluster -o yaml

A possible response may look like this:

apiVersion: v1

data:

  password: Q2h5N1BBY28=

  username: cmVkaXNsYWJzLnNi

kind: Secret

metadata:

  creationTimestamp: 2018-09-03T14:06:39Z

  labels:

   app: redis-enterprise

   redis.io/cluster: test

 name: redis-enterprise-cluster

 namespace: redis

 ownerReferences:

 – apiVersion: app.redislabs.com/v1alpha1

   blockOwnerDeletion: true

   controller: true

   kind: RedisEnterpriseCluster

   name: test

   uid: 8b247469-c715-11e8-a5d5-0a778671fc2e

 resourceVersion: “911969”

 selfLink: /api/v1/namespaces/redis/secrets/redis-enterprise-cluster

 uid: 8c4ff52e-c715-11e8-80f5-02cc4fca9682

type: Opaque

Next, decode, for example, the password field. Run:

echo "Q2h5N1BBY28=" | base64 –-decode

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.”

The scc.yaml file is defined like this:

kind: SecurityContextConstraints
apiVersion: security.openshift.io/v1
metadata:
  name: redis-enterprise-scc
allowPrivilegedContainer: false
allowedCapabilities:
  - SYS_RESOURCE
runAsUser:
  type: MustRunAs
  uid: 1001
FSGroup:
  type: MustRunAs
  ranges: 1001,1001
seLinuxContext:
  type: RunAsAny

(latest version on GitHub)

The psp.yaml file is defined like this:

apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
  name: redis-enterprise-psp
spec:
  privileged: false
  allowPrivilegeEscalation: false
  allowedCapabilities:
    - SYS_RESOURCE
  runAsUser:
    rule: MustRunAsNonRoot
  fsGroup:
    rule: MustRunAs
    ranges:
    - min: 1001
      max: 1001
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  volumes:
    - '*'

(latest version on GitHub)

The SYS_RESOURCE capability is required by the Redis Labs Enterprise Cluster (RLEC) container so that RLEC can set correct OOM scores to its processes inside the container. Also, some of the RLEC services must be able to increase default resource limits, especially the number of open file descriptors.

While the RLEC container runs as user 1001, there are no limits currently set on users and user groups in the default scc.yaml file. The psp.yaml example defines the specific uid.

The RLEC SCC definitions are only applied to the project namespace when you apply them to the namespace specific Service Account as described in the OpenShift Getting Started Guide.

RLEC PSP definitions are controlled with role-based access control (RBAC). A cluster role allowing the RLEC PSP is granted to the redis-enterprise-operator service account and allows that account to create pods with the PSP shown above.