This section contains Kubernetes specific articles which cover various aspects of administering a Redis Enterprise Cluster K8s deployment.

    Kubernetes Operator Deployment – Persistent Volumes

    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. Volume Size volumeSize is an optional definition. By default, if the definition is omitted, Operator allocates five times (5x) the amount of memory (RAM) defined for nodes (see example below), which is the recommended persistent storage size as described in the Hardware requirements article.

    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 – Kubernetes Deployment with Operator

    Redis Labs implements rolling updates for software upgrades in Kubernetes deployments. Rolling updates allow deployments’ updates to take place with zero downtime by incrementally updating Pods’ Redis Enterprise Cluster instances with new ones. The following illustrations depict how a rolling update occurs: Each pentagon represents a node Each box represents a Pod The Pods are updated one by one, in the diagram starting from left to right. Upgrade progresses to the next Pod only once the current Pod has completed the upgrade process successfully.