Redis Cluster Mode
While Redis Sentinel clusters provide excellent failover support, they do not inherently provide data sharding. All data remains on a single Redis instance, limited by its memory and performance capacity. Therefore, it may impact horizontal scalability when dealing with large datasets and high read/write operations.
KubeBlocks now supports Redis Cluster Mode, which not only allows for greater memory distribution but also parallel processing, significantly improving performance for data-intensive operations. A brief overview of Redis Cluster Mode and its basic operations will be elaborated in this documentation.
What is Redis Cluster Mode
Redis Cluster Mode is a distributed deployment mode of the Redis database used to horizontally scale data storage and improve system availability across multiple nodes.
In Redis Cluster Mode, the cluster manages data through a sharding mechanism and provides capabilities for data replication, failover, and traffic routing among shards. This sharding mechanism enables distributing a large amount of data across different nodes, achieving horizontal scalability and load balancing.
Redis Cluster Mode ensures high availability through master-slave replication. Each master node can have one or more slave nodes that replicate the data from the master and provide read services. In case of a master node failure, a slave node can automatically take over the master's role and continue serving, ensuring failover and fault tolerance.
Redis Cluster Mode also provides communication and data migration mechanisms among cluster nodes. When there are changes in the cluster, such as adding nodes, node failures, or node removal, Redis Cluster automatically performs data migration and resharding to maintain data balance and availability.
Basic Ops
Below is a brief introduction to the basic operations of Redis Cluster Mode.
Before you start
-
Install KubeBlocks. Make sure your KubeBlocks and addon are version 0.9 or above.
-
Make sure the Redis Addon is enabled.
-
View all the database types and versions available for creating a cluster.
Make sure you can get the redis
componentdefinition
. It is used to describe and define the components in a database cluster, and usually presents basic information such as the name, type, version, status, etc.kubectl get componentdefinition redis-cluster-7.0
>
NAME SERVICE SERVICE-VERSION STATUS AGE
redis-cluster-7.0 redis-cluster 7.0.6 Available 33m -
To keep things isolated, create a separate namespace called
demo
throughout this tutorial.kubectl create namespace demo
>
namespace/demo created
Create clusters
Since Redis Cluster Mode is based on the latest ShardingSpec API, currently it can only be created by Helm or YAML files using kubectl.
Redis Cluster Mode requires a minimum of three shards, so the number of shards cannot be less than 3.
- Helm
- YAML
# Example 1: Creating a Redis Cluster with three shards, each shard having one replica (one master, one replica)
helm install redisc xxxxx(chart remote address) --set mode=cluster --set redisCluster.shardCount=3 --set replicas=2 -n demo
# Example 2: Creating a Redis Cluster with three shards, each shard having one replica (one master, one replica), and enabling NodePort access
helm install redisc xxxxx(chart remote address) --set mode=cluster --set nodePortEnabled=true --set redisCluster.shardCount=3 --set replicas=2 -n demo
kubectl apply -f redis-cluster-example.yaml
Example 1: Redis Cluster without NodePort enabled
apiVersion: apps.kubeblocks.io/v1alpha1
kind: Cluster
metadata:
name: redisc
namespace: demo
spec:
affinity:
podAntiAffinity: Preferred
topologyKeys:
- kubernetes.io/hostname
clusterVersionRef: redis-7.0.6
shardingSpecs:
- name: shard
# Specify the number of shards, which cannot be less than 3
shards: 3
template:
componentDef: redis-cluster-7
name: redis
replicas: 2
# Specify resources for a single shard
resources:
limits:
cpu: 500m
memory: 512Mi
requests:
cpu: 500m
memory: 512Mi
serviceVersion: 7.0.6
volumeClaimTemplates:
- name: data
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
terminationPolicy: Delete
Example 2: Redis Cluster with NodePort enabled
apiVersion: apps.kubeblocks.io/v1alpha1
kind: Cluster
metadata:
name: redisc
namespace: demo
spec:
affinity:
podAntiAffinity: Preferred
topologyKeys:
- kubernetes.io/hostname
clusterVersionRef: redis-7.0.6
shardingSpecs:
- name: shard
# Specify the number of shards, which cannot be less than 3
shards: 3
template:
componentDef: redis-cluster-7.0
name: redis
replicas: 2
# Specify resources for a single shard
resources:
limits:
cpu: 500m
memory: 512Mi
requests:
cpu: 500m
memory: 512Mi
serviceVersion: 7.0.6
# Enable NodePort
services:
- name: redis-advertised
podService: true
serviceType: NodePort
volumeClaimTemplates:
- name: data
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
terminationPolicy: Delete
Once the cluster is created, wait until the cluster status changes to running
. Then, run kubectl get component -n demo | grep redisc-shard
to view the roles of nodes in the cluster.
kubectl get component -n demo | grep redisc-shard
>
redisc-shard-5hn redis-cluster Running 79m
redisc-shard-7zk redis-cluster Running 79m
redisc-shard-5tw redis-cluster Running 79m
Connect to clusters
- SDK
- Direct connect
Redis Cluster Mode requires using specific client SDKs for connection. Currently, there are Redis Cluster client SDK implementations available in different popular programming languages. You can choose the appropriate SDK based on your requirements. For example, Jedis or Lettuce for Java, go-redis for Golang, etc.
Note that when using an SDK, you need to configure the addresses of each node in the Redis Cluster. According to whether NodePort is enabled or not, there are two different configurations:
Example 1: Redis Cluster without NodePort enabled
Configure each Pod's headless address.
redisc-shard-qst-0.redisc-shard-qst-headless:6379
redisc-shard-qst-1.redisc-shard-qst-headless:6379
redisc-shard-kr2-0.redisc-shard-kr2-headless:6379
redisc-shard-kr2-1.redisc-shard-kr2-headless:6379
redisc-shard-mv6-0.redisc-shard-mv6-headless:6379
redisc-shard-mv6-1.redisc-shard-mv6-headless:6379
Example 2: Redis Cluster with NodePort enabled
Configure each Pod's HostIP and the corresponding NodePort.
# 172.18.0.3 is the host IP of redisc-shard-qst-0 node, and 32269 is the NodePort mapped to the Redis 6379 server port.
172.18.0.3:32269
172.18.0.4:32051
172.18.0.5:32650
172.18.0.6:30151
172.18.0.7:31603
172.18.0.8:31718
Direct connection is only for testing.
For simple connectivity verification, you can use kubectl commands to log in to a specific Pod in the cluster and check the cluster's status.
# Log in to a pod