You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
19
15
20
-
A Redis Enterprise cluster (REC) is deployed as a StatefulSet which manages the Redis Enterprise cluster node pods.
21
-
The scheduler chooses a node to deploy a new Redis Enterprise cluster node pod on when:
16
+
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.
22
17
23
-
- The cluster is created
24
-
- The cluster is resized
25
-
- A pod fails
18
+
Use these options to control pod placement:
26
19
27
-
Here are the ways that you can control the pod scheduling:
20
+
## Use node selectors
28
21
29
-
## Using node selectors
30
-
31
-
The [`nodeSelector`]({{<relref "/operate/kubernetes/reference/api/redis_enterprise_cluster_api#spec">}})
32
-
property of the cluster specification uses the same values and structures as
33
-
the [Kubernetes `nodeSelector`](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#nodeselector).
34
-
In general, node labels are a simple way to make sure that specific nodes are used for Redis Enterprise pods.
35
-
For example, if nodes 'n1' and 'n2' are labeled as "high memory":
22
+
The [`nodeSelector`]({{<relref "/operate/kubernetes/reference/api/redis_enterprise_cluster_api#spec">}}) field matches the Kubernetes [`nodeSelector`](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#nodeselector) syntax.
23
+
Label the nodes you want to target. For example, if nodes 'n1' and 'n2' are labeled with `memory=high`:
36
24
37
25
```sh
38
26
kubectl label nodes n1 memory=high
@@ -52,21 +40,13 @@ spec:
52
40
memory: high
53
41
```
54
42
55
-
Then, when the operator creates the StatefulSet associated with the pod, the nodeSelector
56
-
section is part of the pod specification. When the scheduler attempts to
57
-
create new pods, it needs to satisfy the node selection constraints.
58
-
43
+
The operator copies [`nodeSelector`]({{< relref "/operate/kubernetes/reference/api/redis_enterprise_cluster_api#spec" >}}) into the pod spec. The scheduler places pods only on nodes that match the selector.
59
44
60
-
## Using node pools
45
+
## Use node pools
61
46
62
-
A node pool is a common part of the underlying infrastructure of the Kubernetes cluster deployment and provider.
63
-
Often, node pools are similarly-configured classes of nodes such as nodes with the same allocated amount of memory and CPU.
64
-
Implementors often label these nodes with a consistent set of labels.
47
+
Node pools group similar nodes. Providers label nodes by pool.
65
48
66
-
On Google Kubernetes Engine (GKE), all node pools have the label `cloud.google.com/gke-nodepool` with a value of the name used during configuration.
67
-
On Microsoft Azure Kubernetes System (AKS), you can create node pools with a specific set of labels. Other managed cluster services may have similar labeling schemes.
68
-
69
-
You can use the `nodeSelector` section to request a specific node pool by label values. For example, on GKE:
49
+
Use [`nodeSelector`]({{< relref "/operate/kubernetes/reference/api/redis_enterprise_cluster_api#spec" >}}) to target a pool by label. For example, on GKE:
70
50
71
51
```yaml
72
52
apiVersion: app.redislabs.com/v1
@@ -79,24 +59,36 @@ spec:
79
59
cloud.google.com/gke-nodepool: 'high-memory'
80
60
```
81
61
82
-
## Using node taints
62
+
### Provider resources
63
+
64
+
Cloud providers label nodes by pool. See links below for specific documentation.
65
+
66
+
- GKE:
67
+
- [Create and manage cluster and node pool labels](https://cloud.google.com/kubernetes-engine/docs/how-to/creating-managing-labels)
68
+
- [Update node labels and taints for existing node pools](https://cloud.google.com/kubernetes-engine/docs/how-to/update-existing-nodepools)
69
+
- AKS:
70
+
- [Use labels in an AKS cluster](https://learn.microsoft.com/en-us/azure/aks/use-labels)
71
+
- [Manage node pools in AKS](https://learn.microsoft.com/en-us/azure/aks/manage-node-pools)
72
+
- EKS:
73
+
- [Create a managed node group with labels (AWS CLI)](https://docs.aws.amazon.com/cli/latest/reference/eks/create-nodegroup.html)
74
+
- [Update a managed node group to add labels (AWS CLI)](https://docs.aws.amazon.com/cli/latest/reference/eks/update-nodegroup-config.html)
75
+
76
+
77
+
## Use node taints
83
78
84
-
You can use multiple node taints with a set of tolerations to control Redis Enterprise cluster node pod scheduling.
85
-
The `podTolerations` property of the cluster specification specifies a list of pod tolerations to use.
86
-
The value is a list of [Kubernetes tolerations](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/#concepts).
79
+
Use node taints and pod tolerations to control REC pod scheduling. Set tolerations with [`spec.podTolerations`]({{< relref "/operate/kubernetes/reference/api/redis_enterprise_cluster_api#specpodtolerations" >}}) (standard [Kubernetes tolerations](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/#concepts)).
87
80
88
-
For example, if the cluster has a single node pool, the node taints can control the allowed workloads for a node.
89
-
You can add taints to the node, for example nodes n1, n2, and n3, reserve a set of nodes for the Redis Enterprise cluster:
81
+
Example: on a single node pool, reserve nodes n1–n3 for REC by adding taints:
90
82
91
83
```sh
92
84
kubectl taint nodes n1 db=rec:NoSchedule
93
85
kubectl taint nodes n2 db=rec:NoSchedule
94
86
kubectl taint nodes n3 db=rec:NoSchedule
95
87
```
96
88
97
-
This prevents any pods from being scheduled onto the nodes unless the pods can tolerate the taint `db=rec`.
89
+
This blocks pods unless they tolerate the `db=rec` taint.
98
90
99
-
You can then add the toleration for this taint to the cluster specification:
91
+
Then add a matching toleration to the REC:
100
92
101
93
```yaml
102
94
apiVersion: app.redislabs.com/v1
@@ -107,17 +99,17 @@ spec:
107
99
nodes: 3
108
100
podTolerations:
109
101
- key: db
110
-
operator: Equal
102
+
operator: Equal
111
103
value: rec
112
104
effect: NoSchedule
113
105
```
114
106
115
107
A set of taints can also handle more complex use cases.
116
108
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.
117
109
118
-
## Using pod anti-affinity
110
+
## Use pod anti-affinity
119
111
120
-
By default, the Redis Enterprise node pods are not allowed to be placed on the same node for the same cluster:
112
+
By default, REC node pods are not scheduled on the same node within the same cluster:
121
113
122
114
```yaml
123
115
podAntiAffinity:
@@ -130,10 +122,9 @@ podAntiAffinity:
130
122
topologyKey: kubernetes.io/hostname
131
123
```
132
124
133
-
Each pod has the three labels above where `redis.io/cluster` is the label for the name of your cluster.
125
+
Each pod has these labels. `redis.io/cluster` is your cluster name.
134
126
135
-
You can change this rule to restrict or include nodes that the Redis Enterprise cluster node pods can run on.
136
-
For example, you can delete the `redis.io/cluster` label so that even Redis Enterprise node pods from different clusters cannot be scheduled on the same Kubernetes node:
127
+
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:
137
128
138
129
```yaml
139
130
apiVersion: app.redislabs.com/v1
@@ -151,9 +142,7 @@ spec:
151
142
topologyKey: kubernetes.io/hostname
152
143
```
153
144
154
-
or you can prevent Redis Enterprise nodes from being schedule with other workloads.
155
-
For example, if all database workloads have the label 'local/role: database', you
156
-
can use this label to avoid scheduling two databases on the same node:
145
+
To avoid co-locating with other database workloads, label those pods `local/role: database` and add anti-affinity to keep one database per node:
157
146
158
147
```yaml
159
148
apiVersion: app.redislabs.com/v1
@@ -175,39 +164,36 @@ spec:
175
164
topologyKey: kubernetes.io/hostname
176
165
```
177
166
178
-
In this case, any pods that are deployed with the label `local/role: database` cannot be scheduled on the same node.
167
+
Kubernetes will not schedule two pods with label `local/role: database` on the same node.
179
168
169
+
## Enable rack awareness
180
170
181
-
## Using rack awareness
182
-
183
-
You can configure Redis Enterprise with rack-zone awareness to increase availability
184
-
during partitions or other rack (or region) related failures.
171
+
Enable rack-zone awareness to improve availability during rack or zone failures.
185
172
186
173
{{%note%}}When creating your rack-zone ID, there are some constraints to consider; see [rack-zone awareness]({{< relref "/operate/rs/clusters/configure/rack-zone-awareness#rack-zone-id-rules" >}}) for more info. {{%/note%}}
187
174
188
-
Rack-zone awareness is a single property in the Redis Enterprise cluster CRD named `rackAwarenessNodeLabel`.
175
+
Configure it with [`spec.rackAwarenessNodeLabel`]({{< relref "/operate/kubernetes/reference/api/redis_enterprise_cluster_api#spec" >}}) in the REC.
189
176
190
177
### Choose a node label
191
178
192
179
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](https://kubernetes.io/docs/setup/best-practices/multiple-zones/#nodes-are-labeled).
193
180
194
181
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).
195
182
196
-
### Node labeling requirements
183
+
### Label all eligible nodes
197
184
198
185
{{< warning >}}
199
-
200
-
**All eligible nodes must have the label for rack-awareness to work. The operator requires every node that might run Redis Enterprise pods to be labeled. If any are missing the label, reconciliation will fail.
186
+
All eligible nodes **must** have the label for rack awareness to work. The operator requires every node that might run Redis Enterprise pods to be labeled. If any nodes are missing the label, reconciliation fails.
201
187
{{< /warning >}}
202
188
203
-
Eligible nodes are all nodes where Redis Enterprise pods can be scheduled. By default, these are all worker nodes in the cluster, but you can limit them using `spec.nodeSelector` in the Redis Enterprise cluster (REC) configuration.
189
+
Eligible nodes are nodes where REC pods can run. By default, this means all worker nodes. You can limit eligibility with [`spec.nodeSelector`]({{< relref "/operate/kubernetes/reference/api/redis_enterprise_cluster_api#spec" >}}).
204
190
205
-
The value for the chosen label must indicate the topology information (rack, zone, region, etc.) for each node.
191
+
Give each eligible node a label value that reflects its rack, zone, or region.
206
192
207
-
You can check the value for this label in your nodes with the command:
193
+
Check node label values:
208
194
209
195
```sh
210
-
$ kubectl get nodes -o custom-columns="name:metadata.name","rack\\zone:metadata.labels.topology\.kubernetes\.io/zone"
196
+
kubectl get nodes -o custom-columns="name:metadata.name","rack\\zone:metadata.labels.topology\.kubernetes\.io/zone"
When you use the `rackAwarenessNodeLabel` property, the operator will change the topologyKey for the anti-affinity rule to the label name used unless you have specified the `podAntiAffinity` property as well. If you use `rackAwarenessNodeLabel` and `podAntiAffinity` together, you must make sure that the `topologyKey` in your pod anti-affinity rule is set to the node label name.
233
+
When you set [`spec.rackAwarenessNodeLabel`]({{< relref "/operate/kubernetes/reference/api/redis_enterprise_cluster_api#spec" >}}), the operator sets the anti-affinity `topologyKey` to that label unless you define [`spec.podAntiAffinity`]({{< relref "/operate/kubernetes/reference/api/redis_enterprise_cluster_api#specpodantiaffinity" >}}). If you define both, make sure `topologyKey` matches your node label.
0 commit comments