Skip to content

Commit 7895fce

Browse files
RZA limitation (#1966)
1 parent 5382925 commit 7895fce

File tree

1 file changed

+15
-0
lines changed

1 file changed

+15
-0
lines changed

content/operate/kubernetes/recommendations/node-selection.md

Lines changed: 15 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -282,3 +282,18 @@ spec:
282282
{{< note >}}
283283
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.
284284
{{< /note >}}
285+
286+
### Rack awareness limitations
287+
288+
{{< warning >}}
289+
**Pod restart distribution maintenance**: When rack awareness is enabled, node pods and shards are initially deployed based on rack constraints to ensure proper distribution across zones. However, Redis Enterprise does not automatically maintain this distribution when node pods are restarted.
290+
291+
After pod restarts, the rack awareness policy may be violated, requiring manual intervention to restore proper shard distribution. While Redis Enterprise provides tools to identify shards that need to be moved to restore correct rack distribution, it does not provide automated orchestration to perform these moves.
292+
{{< /warning >}}
293+
294+
**Important considerations for production deployments:**
295+
296+
- At scale, manual shard redistribution can become operationally challenging
297+
- This limitation is particularly important for edge deployments where automated recovery is preferred
298+
- Plan for operational procedures to handle rack awareness policy violations after pod restarts
299+
- Consider monitoring tools to detect when rack awareness constraints are violated

0 commit comments

Comments
 (0)