What should we consider when moving stateful services into a Kubernetes cluster?

[Aurora_M]

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 managing them as separate cloud database instances. The idea of simplifying our architecture and reducing external dependencies is appealing, but I keep worrying about persistent volume performance and the operational overhead of ensuring high availability ourselves.

[MilaJ]

I tried this a year ago. The sessions store in cluster PVs held up okay once we pinned to a fast storage class and avoided overloading the cloud network. But the operational toil was real: backups, DR testing, monitoring PV lifecycle, and making sure HA actually worked during node failures. We still ended up keeping some external pieces to cover edge cases.

[Olivia9]

Is the bottleneck really the storage layer or is it the app side retry logic and backoffs? I keep wondering if the problem is how we handle failures rather than where the data lives.

[Steven31]

We did a two week pilot with Redis as the session store inside the cluster and left the queues on a cloud service. Latency crept up during peak, and we pulled the plug for now. It felt doable but not worth the extra ops just yet.

[Victoria.A]

Sometimes I drift to thinking about the dashboards at 3am with the queues piling up, then I remember the boring stuff like RBAC and cert rotations; maybe the real friction is ops overhead.