Kubernetes provides simpler orchestration with containers and has been widely adopted. It is simple to get a Redis Enterprise cluster on Kubernetes with the Redis Enterprise Operator deployment.

    Redis Labs Kubernetes Architecture

    Redis Labs bases its Kubernetes architecture on several vital concepts. Layered architecture Kubernetes is an excellent orchestration tool, but it was not designed to deal with all the nuances associated with operating Redis Enterprise. Therefore, it can fail to react accurately to internal Redis Enterprise edge cases or failure conditions. Also, Kubernetes orchestration runs outside the Redis Cluster deployment and may fail to trigger failover events, for example, in split network scenarios.

    Redis Enterprise Kubernetes Operator-based Architecture

    The Redis Enterprise Operator is the fastest, most efficient way to deploy and maintain a Redis Enterprise Cluster in Kubernetes. What is an Operator? An Operator is a Kubernetes custom controller which extends the native K8s API. Operators were developed to handle sophisticated, stateful applications that the default K8s controllers aren’t able to handle. While stock Kubernetes controllers—for example, StatefulSets—are ideal for deploying, maintaining and scaling simple stateless applications, they are not equipped to handle access to stateful resources, upgrade, resize and backup of more elaborate, clustered applications such as databases.

    Deploying Kubernetes with Persistent Volumes in Operator-based Architecture

    To deploy a Redis Enterprise Cluster with Redis Enterprise Operator the spec should include a persistentSpec section, in the redis-enterprise-cluster.yaml file: spec: nodes: 3 persistentSpec: enabled: true storageClassName: "standard" volumeSize: "23Gi” #optional Persistence storage is a requirement for this deployment type. Note - For production deployments of Redis Enterprise Cluster on Kubenetes, the Redis Enterprise Cluster (REC) must be deployed with persistence enabled. The REC deployment files in the Kubernetes documentation contain this declaration by default.

    Sizing and Scaling a Redis Enterprise Cluster Kubernetes Deployment

    The following article reviews the mechanism and methods available for sizing and scaling a Redis Enterprise Cluster deployment. For minimum and recommended sizing, always follow the sizing guidelines detailed in the Redis Enterprise Hardware Requirements. Sizing and scaling cluster nodes Setting the number of cluster nodes Define the number of cluster nodes in redis-enterprise-cluster.yaml file. spec: nodes: 3 The number of nodes in the cluster must be an uneven number equal to or greater than 3.

    Upgrading a Redis Enterprise Cluster in Operator-based Architecture

    Redis Labs implements rolling updates for software upgrades in Kubernetes deployments. Upgrading Redis Enterprise in Operator Clone this repository, which contains the deployment files: git clone https://github.com/RedisLabs/redis-enterprise-k8s-docs Example response: Cloning into 'redis-enterprise-k8s-docs'... remote: Enumerating objects: 37, done. remote: Counting objects: 100% (37/37), done. remote: Compressing objects: 100% (30/30), done. remote: Total 168 (delta 19), reused 9 (delta 7), pack-reused 131 Receiving objects: 100% (168/168), 45.32 KiB | 7.

    Redis Enterprise Kubernetes Logs

    Logs 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. This volume can easily be accessed by a sidecar, i.e. a container residing on the same pod. 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: 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 Now the logs can be accessed from in the sidecar.

    Redis Enterprise Cluster Recovery for Kubernetes

    When a Redis Enterprise cluster loses contact with more than half of its nodes either because of failed nodes or network split, the cluster stops responding to client connections. When this happens, you must recover the cluster to restore the connections. You can also perform cluster recovery to reset cluster nodes, to troubleshoot issues, or in a case of active/passive failover. The cluster recovery for Kubernetes automates these recovery steps: