Asking for help? Comment out what you need so we can get more information to help you!
Cluster information:
Kubernetes version: v1.xx.x
Cloud being used: (EKS / GKE / AKS / bare-metal / other)
Installation method: (kops / kubeadm / managed service / other)
Host OS: (e.g., Ubuntu 22.04, Amazon Linux 2)
CNI and version: (e.g., Calico v3.25)
CRI and version: (e.g., containerd 1.7.x, Docker 20.x)
Question:
We are running databases on Kubernetes using StatefulSets.
StatefulSets give stable pod identity and storage, but databases require role-based behavior (master/replica) and dynamic failover without pod restarts.
Our principal engineer raised a concern that using an Operator or a sidecar to manage database roles (e.g., master/replica labels, Services pointing to the primary) is an anti-pattern, since the StatefulSet controller should be the only one managing pods, and another controller mutating them would be “against Kubernetes principles.”
However, most operators (Redis Operator, Patroni, etc.) seem to follow exactly this model:
- StatefulSet manages pod lifecycle/storage.
- Operator manages database logic (failover, role assignment, services).
Is this actually considered an anti-pattern in the Kubernetes community, or is this the intended separation of concerns (infra lifecycle vs application orchestration)?
How do other production systems handle this in a Kubernetes-native way? What is the advised way for role based database systems?