Quick thought from the virtualization/container trenches — running stateful databases inside Kubernetes (yes, it’s doable, but don’t be smug).
I see two common traps: (1) treating K8s like a magic VM host and (2) assuming your storage is «just there». If your DB cares about IOPS, latency, or consistent attachment semantics, design the storage first, then fit K8s around it — not the other way round. StatefulSets + PVCs are useful, but don’t confuse orchestration for data protection: backups, PITR, and healthy replicas remain your safety net.
Practical tips that actually save time:
- Prefer storage classes with known, measured performance (benchmark them under load).
- Make leader election explicit in your deployment (don’t rely solely on pod restart behavior).
- Automate graceful drains so you don’t split-brain under node maintenance.
- Keep resource limits conservative — noisy neighbors are real.
- Use readiness probes that reflect DB readiness (not just TCP port).
- Test node failures and control-plane outages — simulated chaos beats theoretical plans.
In short: containers give agility, but stateful systems demand humility. Ship small, measure often, and have a restore path you trust.
