Should we move stateful workloads like session store into Kubernetes cluster?

[Amelia96]

I’m trying to decide if we should move our stateful services, like our session store and some internal queues, into our main Kubernetes cluster instead of keeping them on separate managed cloud services. The idea of simplifying our architecture with a unified control plane is appealing, but I keep worrying about persistent volume management and the operational overhead if a node fails.

[David84]

Moving the session store into the cluster sounded clean, but during a real outage the PV dance felt messy. We had to juggle storage classes, PVCs, and pod eviction timing, and it reminded me how easy it is to trade one failure mode for another. It’s not always faster to recover when you own the hardware drama.

[Zachary.L]

Are we sure the problem is the storage and queues, or is it the way we model access patterns and backpressure? Sometimes I feel we chase a consolidation win while the real friction is how services talk to each other under load.

[EvelynJR]

We did a tiny pilot in one namespace and pinned a small Redis like session store to a single volume, watched the failover for a couple of hours, and noted latency drift under bursty load. It was eye opening but not conclusive; Kubernetes helped isolate failures but introduced new timing quirks.

[Ethan.W]

Honestly I’m leaning toward keeping the managed services until we see a concrete regression in user sessions, but I’m not confident this is the right signal. The operational overhead can be real, and a failover among nodes sometimes feels unpredictable.