Some workloads translate easily to Kubernetes. Databases, on the other hand, are harder to get right on Kubernetes. Not impossible, but they do come with some challenges that need to be met head-on if you want to get your best performance and keep costs in check.

Access control

One challenge you might face is getting access control right so that developers and database admins have enough access to work with MySQL, PostgreSQL, MongoDB, etc. - but can't accidentally modify other resources that would impact the operation of the Kubernetes cluster.

To counter this, we want to create roles that give developers and DBAs the ability to list their resources and work with custom resources that apply only to their deployed databases. Getting the balance right can be tricky, but through the proper use of Kubernetes Operators and Role-based Access Control (RBAC), you can strike a balance that gives everybody what they need.

Ensuring adequate backups and disaster recovery

You need adequate backups and disaster recovery plans no matter where you're running your databases. This isn't a new challenge, it's just that how you take backups and handle disaster recovery may look different when working with databases on Kubernetes.

How you manage the database to take backups, where backups are stored, and how restores are performed can look very different with Kubernetes.

The good news is that you can use automation, Kubernetes Operators, availability zones, more flexible storage, and more to craft a solid backup plan on Kubernetes. But it's going to look a lot different than what you're doing today.

Managing spend/avoiding overprovisioning

When discussing workloads on Kubernetes we tend to focus on the technology, but it's equally important to consider how our choices impact costs. If you're used to over-engineering solutions (read: throwing a lot of hardware at them), that can be a problem here.

If you're running Kubernetes, there's a good chance you're doing so in the public cloud. When done right, public cloud can be a cost-effective way to run your applications. When done wrong, however, it can be a really good way to burn through your budget.

Traditionally you might be used to over-provisioning your database hardware for peak loads. Clearly, you don't want to do that in the cloud when you are paying for extra computers that you don't need. Choosing the right storage, and instances, all factor into managing your costs.

Proper autoscaling and placement for databases

While we don't want to over-provision, we want to be able to scale up database instances as needed and then (equally importantly) scale back down when demand subsides. This is tricky to get right, particularly the scaling down part.

At the same time, you want to ensure that you're placing your database workloads on the right nodes. You don't want your databases on underpowered instances or specialized instances for GPU computing (for example).

Skills, training, and practices

To quote William Gibson, "the future is already here, it's just not evenly distributed." Likewise, Kubernetes and understanding how to run workloads on Kubernetes is already here - but the knowledge, skills and best practices aren't evenly distributed.

It can be a real challenge to take something that's working in a non-Kubernetes environment and port it successfully to Kubernetes. A big chunk of that is helping teams learn Kubernetes on the job while trying to keep the lights on.

##

To learn more about the transformative nature of cloud native applications and open source software, join us at KubeCon + CloudNativeCon Europe 2023, hosted by the Cloud Native Computing Foundation, which takes place from April 18-21.   

ABOUT THE AUTHOR

Joe Brockmeier Head of Community, Percona

Joe Brockmeier is Head of Community for Percona. He has been involved in open source and technology for more than 20 years. His background includes leadership and community facing roles at Intel, Red Hat, Citrix, and SUSE. He is a member of the Apache Software Foundation, and has been a contributor to numerous open source projects including Fedora, Apache CloudStack, Project Atomic, and CentOS.

When not working, Brockmeier likes to write about tech, music, and culture on his blog, Dissociated Press. He lives in Durham, NC with his family and a menagerie of cats and two dogs.