I've been hearing that running databases on Kubernetes is often considered a bad idea, with many experts recommending services like AWS RDS or ElastiCache instead. I'm curious about the real pros and cons of running databases in Kubernetes. Can someone shed some light on this?
5 Answers
Running databases on Kubernetes isn't inherently problematic, especially with the right operator. But when issues arise and you're lacking expertise, it can be extremely challenging. Managed services can take some of that stress away by providing expert support and SLAs.
True, but even managed services can have their issues. It's about being prepared for whatever challenges come your way.
Using something like a database operator, such as CNPG, can make running databases on Kubernetes feel similar to using RDS. The key is to ensure your storage backend has low latency – avoid NFS if possible. If set up properly, running databases can actually work well!
While NFS may not be ideal, I've found that for smaller workloads, it can suffice as long as everything is configured properly.
We're managing a couple of small Postgres databases with Stackgres, designed specifically for database workloads, and it meets our on-premise needs just fine.
It really depends on your use case. Kubernetes can be great for proofs-of-concept or smaller read-only databases. You can run production databases there, and when set up correctly, it can match the reliability of RDS. However, it often requires a significant time investment to achieve that level of reliability, which might not be worth it for everyone.
Most modern operators like CNPG provide a lot of RDS-like features, making it much easier now than it used to be.
Managing a DB cluster is a serious commitment! If you aren't ready for that challenge, a managed service is the way to go.
There’s no real downside if you know what you're doing! For many businesses, using Kubernetes for databases can save costs and even improve latency. But yes, it does come down to the specific needs and capabilities of your team.
Exactly. Sometimes, there might just be a necessity to keep costs low, even if it means dealing with some potential downtime.
It's all about knowing your workload as well. Some databases just need to be integrated into the Kubernetes lifecycle to function effectively.
Not every organization runs their own cloud! Sometimes, using Kubernetes for databases is a preferred choice, especially if you need certain flexible configurations that managed services can't provide.
Exactly! It’s about finding the right balance between managed services and what Kubernetes can offer. We've done something similar in a large organization.
But don't you have to keep the database in Kubernetes if you go that route?
Absolutely. I often come into organizations where Kubernetes works fine until it doesn’t, and then no one knows how to fix it!