In theory, databases can be run anywhere. Depending on your situation, Kubernetes gives you exactly what you’re looking for.
We at Leafcloud are warm proponents of developing applications according to the DevOps philosophy. But what about the data layer? Hosting databases on Kubernetes is a relatively recent phenomenon, and there are reasons for that. Database servers are stateful, and the databases themselves used to be pretty big, which is the complete opposite of containers. Containers are flexible, compact, and able to run anywhere. Kubernetes has to restart and reschedule pods fairly often. But recent developments in both database trends and Kubernetes have made it a very valid -if not the best- option to run databases.
The advantages of databases on Kubernetes
Some advantages of running databases on Kubernetes are obvious. As with applications, it is a great benefit to be able to spin-up databases rapidly when needed, and that’s something that Kubernetes is perfect for. And after spinning them up, the Kubernetes pod is very scalable. Kubernetes handles the orchestration, so there’s much flexibility to play with. Is the database performing like a dog? Just modify CPU, memory and disk, and it’s back to the races.
Another advantage is that Kubernetes allows to replicate database instances to multiple applications. One of the reasons databases on Kubernetes are generally less challenging than before is that microservices have become very popular, meaning databases are now much smaller than before. This in turn creates the new hassle of having to allocate databases properly, but it’s exactly something that Kubernetes addresses.
And it saves costs, because you can run multiple databases separated from each other in a multitenant environment. As with everything that Leafcloud proposes, Kubernetes is fully free and open source. So no vendor lock-in and no need to buy third-party solutions.
The elephants in the room
The fact that Kubernetes is a wonderful alternative to running databases on a VM doesn’t mean it’s all the same though. First off: what about the requirement of databases to retain all the changes made constantly and the uptime? After all, Kubernetes moves the containers around constantly, disabling them and firing them up again. That issue has been pretty much addressed though. Features like Persistent volumes allow admins to manage data storage volumes. StatefulSets, for its part, tracks pods and ensures the workload state even when switching them around.
But it’s not just Kubernetes that needs to be suited for the database. The database needs to be suited for Kubernetes as well. Anything that improves reliability and fault tolerance will help, as there is always some risk of failover. The ideal database to run on Kubernetes supports replication and sharding, fails over from the master node to read-only nodes, and -of course- support adding and removing instances on demand. If you want more tips, here are some on how to help you out.
All beginnings are tough
The advantages of Kubernetes far outweigh the challenges. Sure, databases might crash more often, but the automated restart means that this will not have any effect on operations. But it’s still crucial to take heed to availability and stability, maybe even more so than other ways of hosting databases. things like provisioning, monitoring, upgrading and patching, scaling, volume expansion, backup and recovery, failure detection and security are all things you need to figure out, especially since they tend to work a little different on Kubernetes as opposed to a VM-hosted or fully managed DB.
It's therefor very important to automate this as much as you can. A great way to do so are Kubernetes Operators. These nifty apps run inside a cluster and take the routine tasks out of the hands of the administrator. It will be familiar enough for developers to take it up and manage the databases themselves and bend them to their will.
Leafcloud will gladly help you out
We're enthusiastic about using Kubernetes for databases, but we are also acutely aware of the challenges and pitfalls. We’ve previously created a tutorial to get you started, and you can find it here. In this example, we’re using Appscode's KubeDB and Stash to create a database on Kubernetes and setup a system for regular backups in a reliable way. And you can read more about this topic here. In case of any question, please do not refrain to contact us. We are always happy to help!