K8s: Flex v2 docs by kaitlynmichael · Pull Request #2855 · redis/docs

kaitlynmichael · 2026-03-05T22:08:25Z

Note

Low Risk
Low risk documentation-only change, but it introduces a new Redis Flex doc section that may overlap with existing re-clusters/redis-flex content and could affect navigation/discoverability.

Overview
Adds a new operate/kubernetes/flex documentation section for Redis Flex, including an overview page plus dedicated Plan, Get started, and Scale guides.

The new docs cover version/feature behavior (including Redis 8.2 key+value offloading and the Redis Flex vs Auto Tiering cutoff), required local NVMe/StorageClass setup via redisOnFlashSpec, database creation via isRof/rofRamSize, sizing guidance, and scaling recommendations/limitations.

^{Written by Cursor Bugbot for commit c681765. This will update automatically on new commits. Configure here.}

github-actions · 2026-03-05T22:08:38Z

DOC-6285

github-actions · 2026-03-05T22:08:39Z

Staging links:
https://redis.io/docs/staging/DOC-6285-k8s-flexv2/operate/kubernetes/flex/
https://redis.io/docs/staging/DOC-6285-k8s-flexv2/operate/kubernetes/flex/auto-tiering/
https://redis.io/docs/staging/DOC-6285-k8s-flexv2/operate/kubernetes/flex/get-started/
https://redis.io/docs/staging/DOC-6285-k8s-flexv2/operate/kubernetes/flex/plan/
https://redis.io/docs/staging/DOC-6285-k8s-flexv2/operate/kubernetes/flex/scale/

jit-ci · 2026-03-05T22:09:36Z

🛡️ Jit Security Scan Results

✅ No security findings were detected in this PR

^{Security scan by Jit}

andy-stark-redis

One minor suggestion but otherwise language LGTM.

andy-stark-redis · 2026-03-13T10:18:07Z

content/operate/kubernetes/flex/scale.md

+
+| Goal | Recommended action |
+|------|--------------------|
+| Increase data capacity only without adding CPU | Increase `memorySize` and decrease RAM percentage |


Maybe these could link to the appropriate sections below?

mich-elle-luna · 2026-03-17T19:44:49Z

Thank you this is looking great

gilcohen-pm · 2026-03-24T12:09:28Z

content/operate/kubernetes/flex/_index.md

+- Operate large distributed caches with elastic scaling and consistent performance under heavy load
+- Reduce infrastructure costs by combining high-speed RAM with cost-efficient flash storage
+
+{{<note>}}Flex does not replace long-term data persistence. For workloads that require durability and recovery across restarts or failures, use Redis persistence features like [AOF (Append-Only File)]({{< relref "/operate/oss_and_stack/management/persistence#append-only-file" >}}), [RDB snapshots]({{< relref "/operate/oss_and_stack/management/persistence#snapshotting" >}}), or both. For more information, see [Database persistence]({{< relref "/operate/rs/databases/configure/database-persistence" >}}).{{</note>}}


I suggest promoting this paragraph into a dedicated section, something like:

## What Flex Isn't Flex is not a durable data store. It is designed for performance, elasticity, and scalability, not for long-term data persistence. While Flex can temporarily retain data in memory or flash, it should not be used as a primary system of record. For workloads that require durability and recovery across restarts or failures, use Redis persistence features like AOF or RDB snapshots.

gilcohen-pm · 2026-03-24T12:14:04Z

content/operate/kubernetes/flex/_index.md

+Redis uses an [LRU (least recently used)]({{< relref "/develop/reference/eviction#apx-lru" >}}) eviction policy to manage data placement. When memory pressure increases, Flex identifies cold objects, transfers them to flash, and frees RAM for new or frequently accessed keys.
+
+This process requires no application changes. Your existing Redis commands work across both storage tiers.
+


I suggest adding an explicit V1 vs V2 comparisson:

Starting with Redis database version 8.2, Flex can offload both keys and values to flash. This increases dataset density per node and frees more RAM for truly hot data, improving RAM hit-rate and enabling larger datasets at predictable latency.

gilcohen-pm · 2026-03-24T12:16:37Z

content/operate/kubernetes/flex/auto-tiering.md

+---
+
+{{<note>}}
+This page applies to Redis database version 7.4 and earlier. If you use version 8.0 or later, see [Redis Flex](https://redis.io/docs/latest/operate/kubernetes/re-clusters/redis-flex).


If this page describes the V2 Flex we should revisit this sentence:
his page applies to Redis database version 8.2 or later and Redis Enterprise for Kubernetes operator 8.0.2-2 or later

gilcohen-pm · 2026-03-24T12:24:05Z

content/operate/kubernetes/flex/plan.md

+- **Active-Active**: Not supported with Flex.
+- **PVC expansion**: Not supported with `redisOnFlashSpec`. Don't enable `enablePersistentVolumeResize` in the REC `persistentSpec`.
+- **Maximum object size**: Keys or values larger than 4 GB remain in RAM only.
+


Add:

Prefer workloads where the working set is significantly smaller than the total dataset and access is biased toward recent data (high RAM hit-rate).

Avoid workloads with very long key names, broad/random access patterns, or very large working sets, which can reduce Flex benefits and increase flash I/O.

gilcohen-pm · 2026-03-24T12:59:09Z

content/operate/kubernetes/flex/scale.md

+
+You can add more shards or nodes to distribute traffic and increase throughput without changing the RAM-to-flash ratio. Dataset size capacity also typically increases as a result of additional shards and infrastructure. This strategy is recommended when the dataset size and traffic are expected to grow together.
+
+Before you add shards or nodes, you need to add more RAM and vCPUs to handle the increased number of shards or nodes.


Let's explicitly this a bit and highlight the tradeoff: This increases capacity and potential throughput but requires more RAM, vCPUs, and a rebalance operation.

gilcohen-pm · 2026-03-24T12:59:38Z

content/operate/kubernetes/flex/scale.md

+
+To improve throughput and lower latency, you can expand the in-memory tier to serve a higher proportion of requests directly from RAM. This strategy is recommended when low latency is your primary goal and you don't need to increase the dataset size.
+
+Before increasing the RAM-to-flash ratio, you might need to add more nodes to accommodate additional RAM.


same here: This improves throughput and lowers latency by serving more requests from RAM, at the cost of higher RAM usage.

gilcohen-pm · 2026-03-24T13:00:22Z

content/operate/kubernetes/flex/scale.md

+### Decrease RAM-to-flash ratio
+
+You can allocate more data to the flash tier to increase the database capacity while keeping the same amount of RAM, shards, and vCPU. This strategy is recommended when scaling for volume only and SSD resources are underutilized.
+


This increases capacity without adding CPU or RAM but can lower RAM hit-rate and increase p99 latency; monitor metrics before and after the change.

AI rough draft

c681765

kaitlynmichael self-assigned this Mar 5, 2026

kaitlynmichael marked this pull request as ready for review March 6, 2026 16:44

kaitlynmichael marked this pull request as draft March 6, 2026 16:45

kaitlynmichael added k8s do not merge yet labels Mar 6, 2026

kaitlynmichael added 10 commits March 6, 2026 15:01

index page edits

188d176

small format edit

d31eb17

add compatibility

1189a92

utilization aware RAM

99ae1cf

database verison table

ee15531

fix build failure

a1ef947

plan page edits

8f52144

edit scaling page

9abb0e5

add auto tiering and edit get started

b660e22

remove old page add alias

c742735

kaitlynmichael marked this pull request as ready for review March 12, 2026 19:48

kaitlynmichael requested review from a team, gilcohen-pm and heinrich-redislabs March 12, 2026 19:48

andy-stark-redis approved these changes Mar 13, 2026

View reviewed changes

gilcohen-pm reviewed Mar 24, 2026

View reviewed changes

		Redis uses an [LRU (least recently used)]({{< relref "/develop/reference/eviction#apx-lru" >}}) eviction policy to manage data placement. When memory pressure increases, Flex identifies cold objects, transfers them to flash, and frees RAM for new or frequently accessed keys.

		This process requires no application changes. Your existing Redis commands work across both storage tiers.


		You can add more shards or nodes to distribute traffic and increase throughput without changing the RAM-to-flash ratio. Dataset size capacity also typically increases as a result of additional shards and infrastructure. This strategy is recommended when the dataset size and traffic are expected to grow together.

		Before you add shards or nodes, you need to add more RAM and vCPUs to handle the increased number of shards or nodes.


		To improve throughput and lower latency, you can expand the in-memory tier to serve a higher proportion of requests directly from RAM. This strategy is recommended when low latency is your primary goal and you don't need to increase the dataset size.

		Before increasing the RAM-to-flash ratio, you might need to add more nodes to accommodate additional RAM.

		### Decrease RAM-to-flash ratio

		You can allocate more data to the flash tier to increase the database capacity while keeping the same amount of RAM, shards, and vCPU. This strategy is recommended when scaling for volume only and SSD resources are underutilized.

Conversation

kaitlynmichael commented Mar 5, 2026 • edited by cursor bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Mar 5, 2026 • edited by atlassian bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Mar 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jit-ci bot commented Mar 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🛡️ Jit Security Scan Results

Uh oh!

andy-stark-redis left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mich-elle-luna commented Mar 17, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

kaitlynmichael commented Mar 5, 2026 •

edited by cursor bot

Loading

github-actions bot commented Mar 5, 2026 •

edited by atlassian bot

Loading

github-actions bot commented Mar 5, 2026 •

edited

Loading

jit-ci bot commented Mar 5, 2026 •

edited

Loading