DEV Community

Vijay Kodam
Vijay Kodam

Posted on

Do you run your database on Kubernetes?

Do you run your database on Kubernetes? This has been an evergreen debate. Where does it stand now?

Kubernetes has come a long way from running only stateless workloads early on to now supporting statefulsets with improvements in sticky identity, persistent storage and unique network identity. Kubernetes has democratized the container orchestration and given the world tools to run most software at scale. This is only one part of the solution.

Databases built to run directly on servers or virtual machines have different features to make them highly available, resilient and scalable. Now if you bring those databases and run them on Kubernetes then it is a recipe for disaster. In the recent years, there have been cloud native databases built to run on Kubernetes. This is the remaining part of the solution.

You have a container orchestrator platform like Kubernetes which runs most of your software and now with cloud-native databases, you can run them on Kubernetes too.

Best of both worlds? What about latency? How do you handle frequent k8s release upgrades every three months? Now with EKS Auto mode, the worker nodes max lifetime is just 21 days. Imagine moving around your database nodes every two-three weeks? Is it recommended in production? Do you instead use managed database service from hashtag#AWS hashtag#GoogleCloud or hashtag#Azure?

There is no right or wrong answer and "It Depends" on the software architecture and business constraints.

I would like to hear from you all. Write your opinion in the comments below. Do you run your database on Kubernetes? Why? Why not? What are your reasons? Are you using it in production? What is the adoption for such databases?

Top comments (2)

Collapse
 
pengtan profile image
Peng Tan

Sql, NoSql, NewSql databases run on Kubernetes and for both production and test. And all databases are deployed in helm charts.
Reason:

  • All applications (clients) are on Kubernets.
  • It is trend, more and more developers have already worked for k8s env in community for production env for different DBs, so work on k8s are good for now and future.
  • All cloud providers can provide SQL/NoSQL solution. Most NewSQL are for K8s from day 1. So it would be easy to migrate to these cloud providers' env if customers use similar env.
  • Good for customers to manage applictions in one style. And it would be easy for customers to accept the solution if it is trend even it would bring some drawbacks, because these drawbacks will be less.
  • Need good applications arch (e.g., need cache to enhance perf and reduce latency, can read only when DB is down/upg, provide tricky solution during DB upgrade/downgrade to reduce DB downtime or friendly user experience, etc)
  • Need solution level solution to consider when one site application or DB is down or upg, traffic should be reroute, e.g., geo-red solution.
  • Many ... So need more experiented developers to maintain the DBs in k8s for customers(lifecycle for upg/downgrade, scaling, resilience cases, data backup/restore, recovery etc. Back-to-back collaboration with DB community members (or cloud providers) is essential.
Collapse
 
vijaykodam profile image
Vijay Kodam

good points. What about the stability, high availability of the database?
How do you handle the occasional failures or node crashes or node scaling in your kubernetes? How does it affect the DB?
How do you upgrade k8s while keeping database always available?