If you are talking about running Redis Operators, some folks will run them cluster-wide if they don’t have too many Redis Servers to manage, and others will run them for sets of namespaces or applications, based on some operator class, or limiting specifically by namespaces. Usually we see the namespaced based approach when it comes to multi-tenanted environments, and environments where system namespaces should not be included in the Operator for security blast radius. We also see the namespaces versions running when we are working with very big clusters. We’ve seen clusters with 2000+ nodes, and 60+ Redis Clusters. In this case we usually run multi versions of the same Operator, covering different namespaces, to help with upgrade blast radius, as well as performance when managing a lot of Redis Clusters.

I did some asking internally, and I found out why we had one big redis cluster right now, because each application share login sessions in the redis cluster

So I’ll probably create a redis cluster in the login namespace, and then write some network policies that’ll allow those backends in other namespaces, to talk to that redis. Until those applications gets a better way of doing it

Would you mind sharing a link for your Redis Operator?

Absolutely https://github.com/ContainerSolutions/redis-cluster-operator

Live upgrades are WIP and will be working within the next couple weeks 🙂

So when those get migrated to k8s, it would be one redis cluster in one of the application namespaces, probably login namespace, and let the backends talk to the redis svc in the login namespace. Then do the same for each cluster (dev, staging, production)