How to Run Redis Natively on Kubernetes: Architecture & Ops Guide

Redis Overview

Redis is a widely used in‑memory key‑value store, ranking first on DB‑Engines. It supports strings, hashes, lists, sets, streams and offers features such as replication, persistence (RDB/AOF), Sentinel for high availability and native clustering.

Replication : asynchronous full and incremental sync from master to slaves.

Persistence : data can be persisted via RDB or AOF.

Sentinel : monitors master health and performs failover.

Cluster mode : sharding with a share‑nothing architecture, each shard can have one master and multiple slaves.

Typical use cases include caching, KV database, and message queue via streams.

Kubernetes Basics

Kubernetes (K8s) automates container deployment, scaling and management. Core features include automatic bin‑packing, DNS‑based service discovery, load balancing, various workload resources (Deployment, DaemonSet, StatefulSet, CronJob/Job) and self‑healing.

Redis Cloud‑Native Architecture

The architecture consists of three components: Server (stateful shards), Proxy (stateless request router) and ConfigServer (stateless configuration store backed by etcd). ConfigServer tracks shard topology, performs health checks, triggers failover and updates Proxy topology.

Deployments:

ConfigServer and Proxy are deployed as Deployments (stateless).

Each shard’s Server is managed by a StatefulSet; the first pod in a shard is the initial master.

Secrets store Redis credentials, mounted into Server pods. Proxy scaling uses HPA based on CPU usage.

Placement Strategies

Pods of the same shard must not co‑locate on the same node (PodAntiAffinity required).

Proxy pods should be spread across nodes using preferred anti‑affinity and topology spread constraints.

Storage

Persistent volumes are provisioned via PVC + PV with a dynamic StorageClass, abstracting underlying storage back‑ends.

Redis Cloud‑Native Features

An Operator implements the Operator pattern to reconcile a custom RedisCluster resource, managing lifecycle, scaling and upgrades. All Redis components are cloud‑native.

Cluster Creation Workflow

Client sends a creation request to the API server.

Operator watches the request and creates StatefulSets for Server shards.

After all Server pods are ready, Operator registers them with ConfigServer.

ConfigServer establishes master‑slave relationships via SLAVEOF.

Operator creates Proxy Deployment once topology is ready.

Shard Scaling

Horizontal scaling adds new StatefulSet shards; Operator registers them, guides master‑slave setup and data migration. Shrinking follows the reverse process, ensuring data is rebalanced before deleting StatefulSets.

Component Upgrade

Proxy upgrades are simple image updates. Server upgrades are performed pod‑by‑pod: the pod is removed from ConfigServer topology (with failover if it is master), a 30‑second grace period ensures proxies have refreshed topology, then the pod is recreated and re‑registered.

Summary & Outlook

The talk demonstrated how to abstract stateful services like Redis onto K8s, covering architecture, deployment, scaling and upgrades. Future work includes finer‑grained resource management, dynamic scaling and deeper automation to improve operational efficiency.