Edu/Supportk8s_redis_summary
Overall evaluation of Redis topologies on Kubernetes
Overall Redis topology evaluation
| Redis / Pod topology | HA Status (HA) | Scalability (scalability) | *3-Pod limit |
|---|---|---|---|
| Redis-Cluster (6 Pods) (3 Masters, 3 Replicas) | O (Pass) | O (Pass) | X (Fail) |
| Redis-Sentinel (6 Pods) (1 Master, 2 Replicas, 3 Sentinels) | O (Pass) | X (Fail) | X (Fail) |
| Redis-Sentinel (3 Pods) (Sidecar: Redis and Sentinel in one Pod) | △ (Warning) | X (Fail) | O (Pass) |
| Redis-Standalone (1Pod) (1 master) | X (Fail) | X (Fail) | O (Pass) |
* 3-Pod limit: a score for environments that cap Pods at three (often because early design skipped Sentinel HA/scale needs). If Pod count is not limited, you can ignore this column.
🧑💻 Architecture conclusion
- Redis-Cluster (6 Pods): Meets HA and scale for growing data/traffic, so it is the top production recommendation.
✅ If one master dies, the other two keep serving. Impact is a partial 1/3-zone outage, not a full stop. - Redis-Sentinel (6 Pods): Single master can bottleneck on writes. Reads can go to replicas, but extra replicas do not remove the write bottleneck.
- Redis-Sentinel sidecar (3 Pods): One Pod failure stops Redis and Sentinel together, so stability is weaker. Two Pods down at once can miss Sentinel quorum and delay or block failover.
- Redis-Standalone (1 Pod): If Redis uses ≤1GB and ~30s of downtime is acceptable, a single master can work. (The 1GB cap is because larger datasets take longer to load from AOF. If you disable AOF/RDB, ignore the memory cap.)
| << K8s Redis Scale-Out |
|---|
Email
답글이 올라오면 이메일로 알려드리겠습니다.
