Control node selection

This section provides information about how Redis Enterprise cluster pods can be scheduled to only be placed on specific nodes or node pools.

Kubernetes clusters often include nodes with different CPU and memory profiles. You control where Redis Enterprise cluster (REC) pods run by setting fields in the REC custom resource (CRD).

A Redis Enterprise cluster (REC) runs as a StatefulSet. The Kubernetes scheduler assigns nodes when you create or resize the cluster, or when a pod restarts.

Use these options to control pod placement:

Use node selectors

The nodeSelector field matches the Kubernetes nodeSelector syntax. Label the nodes you want to target. For example, if nodes 'n1' and 'n2' are labeled with memory=high:

kubectl label nodes n1 memory=high
kubectl label nodes n2 memory=high

The Redis Enterprise cluster CRD can request to be scheduled on these nodes:

apiVersion: app.redislabs.com/v1
kind: RedisEnterpriseCluster
metadata:
  name: rec
spec:
  nodes: 3
  nodeSelector:
     memory: high

The operator copies nodeSelector into the pod spec. The scheduler places pods only on nodes that match the selector.

Use node pools

Node pools group similar nodes. Providers label nodes by pool.

Use nodeSelector to target a pool by label. For example, on GKE:

apiVersion: app.redislabs.com/v1
kind: RedisEnterpriseCluster
metadata:
  name: rec
spec:
  nodes: 3
  nodeSelector:
     cloud.google.com/gke-nodepool: 'high-memory'

Provider resources

Cloud providers label nodes by pool. See links below for specific documentation.

• GKE:
  • Create and manage cluster and node pool labels
  • Update node labels and taints for existing node pools
• AKS:
  • Use labels in an AKS cluster
  • Manage node pools in AKS
• EKS:
  • Create a managed node group with labels (AWS CLI)
  • Update a managed node group to add labels (AWS CLI)

Use node taints

Use node taints and pod tolerations to control REC pod scheduling. Set tolerations with spec.podTolerations (standard Kubernetes tolerations).

Example: on a single node pool, reserve nodes n1–n3 for REC by adding taints:

kubectl taint nodes n1 db=rec:NoSchedule
kubectl taint nodes n2 db=rec:NoSchedule
kubectl taint nodes n3 db=rec:NoSchedule

This blocks pods unless they tolerate the db=rec taint.

Then add a matching toleration to the REC:

apiVersion: app.redislabs.com/v1
kind: RedisEnterpriseCluster
metadata:
  name: rec
spec:
  nodes: 3
  podTolerations:
  - key: db
    operator: Equal
    value: rec
    effect: NoSchedule

A set of taints can also handle more complex use cases. For example, a role=test or role=dev taint can be used to designate a node as dedicated for testing or development workloads via pod tolerations.

Use pod anti-affinity

By default, REC node pods are not scheduled on the same node within the same cluster:

podAntiAffinity:
  requiredDuringSchedulingIgnoredDuringExecution:
  - labelSelector:
      matchLabels:
        app: redis-enterprise
        redis.io/cluster: rec
        redis.io/role: node
    topologyKey: kubernetes.io/hostname

Each pod has these labels. redis.io/cluster is your cluster name.

Modify this rule to widen or narrow placement. For example, remove the redis.io/cluster label to prevent pods from different clusters from sharing a node:

apiVersion: app.redislabs.com/v1
kind: RedisEnterpriseCluster
metadata:
  name: rec
spec:
  nodes: 3
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
    - labelSelector:
        matchLabels:
          app: redis-enterprise
          redis.io/role: node
      topologyKey: kubernetes.io/hostname

To avoid co-locating with other database workloads, label those pods local/role: database and add anti-affinity to keep one database per node:

apiVersion: app.redislabs.com/v1
kind: RedisEnterpriseCluster
metadata:
  name: rec
spec:
  nodes: 3
  extraLabels:
     local/role: database
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
    - labelSelector:
        matchLabels:
          local/role: database
          app: redis-enterprise
          redis.io/cluster: rec
          redis.io/role: node
      topologyKey: kubernetes.io/hostname

Kubernetes will not schedule two pods with label local/role: database on the same node.

Enable rack awareness

Enable rack-zone awareness to improve availability during rack or zone failures.

Configure it with spec.rackAwarenessNodeLabel in the REC.

Choose a node label

The most common label used for rack-zone awareness is topology.kubernetes.io/zone, a standard Kubernetes label that shows the zone a node runs in. Many Kubernetes platforms add this label to nodes by default, as noted in the Kubernetes documentation.

If your platform doesn’t set this label automatically, you can use any custom label that describes the node’s topology (such as rack, zone, or region).

Label all eligible nodes

Eligible nodes are nodes where REC pods can run. By default, this means all worker nodes. You can limit eligibility with spec.nodeSelector.

Give each eligible node a label value that reflects its rack, zone, or region.

Check node label values:

kubectl get nodes -o custom-columns="name:metadata.name","rack\\zone:metadata.labels.topology\.kubernetes\.io/zone"

name                                            rack\zone
ip-10-0-x-a.eu-central-1.compute.internal    eu-central-1a
ip-10-0-x-b.eu-central-1.compute.internal    eu-central-1a
ip-10-0-x-c.eu-central-1.compute.internal    eu-central-1b
ip-10-0-x-d.eu-central-1.compute.internal    eu-central-1b

Enable the cluster role

Grant the operator read access to node labels with a ClusterRole and ClusterRoleBinding.

ClusterRole:

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: redis-enterprise-operator
rules:
  # needed for rack awareness
  - apiGroups: [""]
    resources: ["nodes"]
    verbs: ["list", "get", "watch"]

Bind to the redis-enterprise-operator service account:

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: redis-enterprise-operator
  labels:
    app: redis-enterprise
subjects:
- kind: ServiceAccount
  namespace: NAMESPACE_OF_SERVICE_ACCOUNT
  name: redis-enterprise-operator
roleRef:
  kind: ClusterRole
  name: redis-enterprise-operator
  apiGroup: rbac.authorization.k8s.io

Apply these files with kubectl apply. For example:

kubectl apply -f rack-aware-cluster-role.yaml
kubectl apply -f rack-aware-cluster-role-binding.yaml

After you apply the role and binding, you can configure rack awareness.

Configure rack awareness

Set spec.rackAwarenessNodeLabel to the node label to use:

apiVersion: app.redislabs.com/v1alpha1
kind: RedisEnterpriseCluster
metadata:
  name: rack-aware-cluster
  labels:
    app: redis-enterprise
spec:
  nodes: 3
  rackAwarenessNodeLabel: topology.kubernetes.io/zone

Rack awareness limitations

Important considerations for production deployments:

• At scale, manual shard redistribution can become operationally challenging
• This limitation is particularly important for edge deployments where automated recovery is preferred
• Plan for operational procedures to handle rack awareness policy violations after pod restarts
• Consider monitoring tools to detect when rack awareness constraints are violated