Getting Started with Redis Enterprise Software using Kubernetes
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 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.
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.
A primer to configuration options for Redis Enterprise cluster Custom Resource Definitions.
The database controller provides the ability to create, manage, and use databases via a database custom resource.
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.
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.
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.55 MiB/s, done.
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.
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:
Redis Enterprise cluster pods can be scheduled to only be placed on specific nodes or node pools.
You can use quality of service, priority class, eviction thresholds and resource monitoring to maintain cluster node pod stability.
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.