Rack awareness examples
YAML examples for rack-aware Redis Enterprise deployments that distribute nodes across availability zones.
Redis Enterprise for Kubernetes |
---|
This page provides YAML examples for deploying Redis Enterprise with rack awareness. Rack awareness distributes Redis Enterprise nodes and database shards across different availability zones or failure domains to improve high availability and fault tolerance.
Prerequisites
- Label Kubernetes nodes with zone information
- Typically uses the standard label
topology.kubernetes.io/zone
- Verify node labels:
kubectl get nodes --show-labels
- Install the Redis Enterprise operator
For complete deployment instructions, see Deploy on Kubernetes.
Service account
The service account for rack-aware deployments is the same as basic deployments.
Cluster role
Rack awareness requires additional permissions to read node labels across the cluster.
Cluster role configuration:
name
: ClusterRole name for rack awareness permissionsrules
: Permissions to read nodes and their labels cluster-wideresources
: Access tonodes
resource for zone label discovery
Key permissions:
nodes
: Read access to discover node zone labelsget, list, watch
: Monitor node changes and zone assignments
Cluster role binding
The ClusterRoleBinding grants cluster-wide permissions to the service account.
Cluster role binding configuration:
subjects.name
: Must match the service account namesubjects.namespace
: Namespace where the operator is deployedroleRef.name
: Must match the cluster role name
Rack-aware Redis Enterprise cluster
The rack-aware REC configuration includes the rackAwarenessNodeLabel
field.
Rack-aware cluster configuration:
metadata.name
: Cluster name (cannot be changed after creation)spec.rackAwarenessNodeLabel
: Node label used for zone identificationspec.nodes
: Minimum 3 nodes, ideally distributed across zones
Edit the values in the downloaded YAML file based on your environment, such as increasing nodes for better zone distribution, using custom zone labels, adding resource specifications, or enabling persistent storage.
Common zone labels
Different Kubernetes distributions use different zone labels:
Standard
:topology.kubernetes.io/zone
Legacy
:failure-domain.beta.kubernetes.io/zone
Custom
: Your organization's specific labeling scheme
Verify the correct label on your nodes:
kubectl get nodes -o custom-columns=NAME:.metadata.name,ZONE:.metadata.labels.'topology\.kubernetes\.io/zone'
Redis Enterprise database
Database configuration for rack-aware clusters is the same as basic deployments.
Important: For rack awareness to be effective, ensure your database has replication enabled. Rack awareness distributes primary and replica shards across zones, so databases without replication will not benefit from zone distribution.
Apply the configuration
To deploy rack-aware Redis Enterprise clusters, follow Deploy on Kubernetes and ensure your Kubernetes nodes have proper zone labels. For detailed rack awareness configuration, see the node selection recommendations.
Troubleshooting
Nodes not distributed across zones
- Verify node labels are correct
- Check that sufficient nodes exist in each zone
- Ensure the
rackAwarenessNodeLabel
matches actual node labels
Cluster role permissions denied
- Verify the ClusterRole and ClusterRoleBinding are applied
- Check that the service account name matches in all resources
Database shards not distributed
- Confirm the cluster has rack awareness enabled
- Check that the database has replication enabled - rack awareness distributes primary/replica pairs across zones
- Verify the database has multiple shards
- Ensure sufficient nodes exist across zones
Next steps
- Configure Active-Active databases
- Set up multi-namespace deployment
- Learn about database replication