Should I move a Redis cache into my Kubernetes cluster or keep it external?

[Ronald.M]

I’m trying to decide if we should move our stateful services, like our Redis caching layer, into our main Kubernetes cluster or keep them as managed services outside of it. I’m worried about the operational overhead of managing persistent volumes and ensuring high availability ourselves, but the latency and cost of external services is becoming noticeable.

[AndrewTJ]

We experimented with moving the cache into the Kubernetes cluster using a StatefulSet and a storage class. It seemed fine at first, but failovers during maintenance added noticeable latency and we constantly fought with backups, restores, and storage throttling. The operational overhead kept creeping in even with decent YAMLs and operators.

[Ella.W]

We kept it as a managed service outside. The ops load dropped a lot—no more manual PV tinkering, upgrades handled by the vendor, and failover transparent. Latency stayed reasonable for most paths, but we did see a cost bump and occasional cross-zone hops that showed up in dashboards.

[Sofia.S]

If you try to weigh it, the in cluster option gives you potential low latency on local reads, but it also invites drift and upgrade headaches. In practice, teams end up trading one set of issues for another, and it's not always clear which side is actually easier to run day to day.

[ThomasRL]

Do you actually need sub millisecond cache for every path, or is near locality enough? Maybe a hybrid approach could work, keeping hot keys in the cluster while relying on a managed service for durability.