limits.memory 必须严格大于 redis 的 maxmemory，因 kubelet 依据容器 rss 内存（含 redis 各类开销）判断超限，而 maxmemory 仅限制数据层；实测 1gb maxmemory 对应 rss 常达 1.2–1.4gb，若 limits 设为 1gi 将频繁触发 oomkilled 或驱逐。
必须让 resources.limits.memory 严格大于 Redis 的 maxmemory，否则 Pod 极大概率被 kubelet 驱逐 —— 这不是配置建议，是 K8s 内存管理的硬性约束。
为什么 limits.memory 必须 > maxmemory
Kubelet 判断 Pod 是否超限，依据的是整个容器进程的 RSS 内存（含 Redis 自身开销、AOF/RDB 缓冲、复制积压缓冲、Lua 脚本内存、连接对象等），而 maxmemory 只控制 Redis 数据层的内存上限。实测中，一个设为 1gb 的 maxmemory，RSS 常达 1.2–1.4gb。
若 limits.memory 设为 1Gi，Kubelet 会持续触发 cgroup OOM killer，Pod 状态反复变为 OOMKilled 或被静默驱逐。
常见错误现象：
-
kubectl describe pod redis-0中出现OOMKilled或reason: Evicted -
kubectl top pod显示内存使用率长期 >95%，但redis-cli info memory | grep used_memory_human却只有 700MB 左右 - 日志里没有 Redis 报错，但连接频繁断开、
cluster nodes显示节点失联
如何设置合理的 limits 和 maxmemory 差值
差值不是拍脑袋定的，要结合 Redis 实际负载模式估算：
- 纯缓存场景（无 AOF、无 RDB、少量连接）：
limits.memory = maxmemory × 1.25（例如maxmemory: "1gb"→limits.memory: "1280Mi"） - 开启 AOF（everysec）+ 持久化写入中等：+30% 安全余量（
"1312Mi"） - 高写入 + 大 key + Lua 脚本频繁：至少 +40%，并观察
used_memory_rss_human与used_memory_human的比值（理想值 - 集群模式下，每个节点都需单独校验该关系，不能只看主节点
不要用 2Gi 这种粗粒度值硬套；也不要依赖 “反正我留了 buffer” —— buffer 不够时，驱逐就发生在毫秒级。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
StatefulSet 中必须显式声明 resources 和 maxmemory
在 Redis StatefulSet 的 container 定义中，这两项必须同时存在且可验证：
resources:
requests:
memory: "1024Mi"
cpu: "100m"
limits:
memory: "1280Mi" # 必须 > maxmemory
cpu: "500m"
command: ["redis-server", "/etc/redis/redis.conf"]
volumeMounts:
- name: config
mountPath: /etc/redis/redis.conf
subPath: redis.conf
对应的 redis.conf 内容必须包含：
-
maxmemory 1024mb（注意单位统一，推荐用mb或gb，避免字节换算出错） -
maxmemory-policy volatile-lfu（或你选定的策略） - 禁用
maxmemory-samples默认值以外的非常规调优，除非有压测数据支撑
ConfigMap 挂载后，务必进 Pod 执行：redis-cli config get maxmemory 和 cat /sys/fs/cgroup/memory/memory.limit_in_bytes（换算成 MiB）做双重校验。
上线前必做的三件事
缺一不可，否则等于裸奔：
- 用
kubectl exec -it redis-0 -- sh -c 'echo $(($(cat /sys/fs/cgroup/memory/memory.limit_in_bytes) / 1024 / 1024))Mi'确认实际生效的 limits 值 - 连上 Redis 后执行
INFO memory，核对maxmemory、used_memory_rss、mem_allocator三项 - 模拟写压测（如
redis-benchmark -n 100000 -q -t set,get），观察kubectl top pod是否稳定在 limits 的 85% 以下
最易被忽略的点：很多人只校验了初始状态，却没在 AOF rewrite 或主从全量同步期间观察 RSS 峰值 —— 那个瞬间才是驱逐高发期。
