在 Kubernetes 上运行 Redis 集群：学习笔记与技术方案调研

在 Kubernetes 上运行 Redis 这类有状态应用面临着独特的挑战。本文是对主流技术方案的学习整理，可作为实际部署前的参考。

核心挑战

Redis 本质上是有状态服务，而 Kubernetes 的原生设计偏向无状态应用。弥合这一 gap 需要综合考虑：

• 数据持久化方案
• 网络拓扑设计
• 扩缩容策略
• 故障转移处理
• 性能优化

架构方案对比

方案一：Redis Sentinel

使用 Sentinel 实现高可用的传统方案：

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: redis
spec:
  serviceName: redis
  replicas: 3
  template:
    spec:
      containers:
      - name: redis
        image: redis:7-alpine
        command: ["redis-server", "--sentinel"]

优势：方案成熟，文档完善 劣势：需手动配置故障转移，扩展能力有限

方案二：Redis Cluster

用于水平扩展的原生集群方案：

apiVersion: redis.redis.opstreelabs.in/v1beta1
kind: RedisCluster
metadata:
  name: redis-cluster
spec:
  clusterSize: 6
  persistenceEnabled: true

优势：自动分片，内置故障转移 劣势：不支持跨槽操作，配置复杂度较高

方案三：Operator 方案

使用 Redis Operator 进行自动化管理。目前社区中较为成熟的实现包括 redis-operator（opstree）等。

优势：简化运维，自动化程度高 劣势：引入了额外的抽象层

生产配置参考

以下为技术调研中整理的关键配置项：

资源预留

resources:
  requests:
    memory: "2Gi"
    cpu: "1000m"
  limits:
    memory: "4Gi"
    cpu: "2000m"

Redis 需要稳定的 CPU 以保证性能，应避免过度超卖。

AOF 持久化

args:
  - redis-server
  - --appendonly yes
  - --appendfsync everysec

以部分性能换取数据持久性。若纯用作缓存，可关闭持久化。

监控指标

需要关注的关键指标：

1. 内存使用：used_memory_rss 与 maxmemory 的对比
2. 逐出量：evicted_keys —— 指示内存压力
3. 慢查询：slowlog —— 性能瓶颈定位
4. 连接数：connected_clients —— 连接池状况
5. 复制延迟：主从架构中的数据同步延迟

说明

本文为技术调研与学习笔记，部分配置来源于社区最佳实践的整理。