Is your database on Kubernetes production-ready?

Last May, KubeCon gathered multiple tech enthusiasts, students, professionals, and companies. The event highlighted various topics and insights on how to collaborate on pushing the boundaries of cloud-native computin

One of our Engineering Directors, Mykola Marzhan, shared his knowledge about databases on Kubernetes at KubeCon, during a session organised by the DoK.Community.

We’ve picked out some of the key highlights from the talk below.

Watch the online session

Why use Kubernetes to run databases?

Organisations want to build and run scalable database applications in public, private and hybrid environments. There are multiple pros and cons to running database applications in Virtual Machines (VMs), Database as a Service (DBaaS) and Kubernetes. Versus VMs and DBaaS, running a database on Kubernetes has benefits in portability, avoiding vendor lock-in, DevOps friendliness, scalability and cost-effectiveness

Today, most organisations want to run databases as a stateful workload. Kubernetes can cater for this requirement. 

Charmhub.io has published multiple database operators (called charms) that run on Kubernetes, including Redis, Cassandra, PostgreSQL, etc. A charm is a database operator running in Kubernetes as an application package with all the operational knowledge required to install, maintain and upgrade it on a Kubernetes cluster. A charm can also integrate with other applications and charms.

Checklist for a production-ready database on Kubernetes

Organisations deploy multiple applications for their business operations, often including databases. Deploying database clusters faster and confidently is necessary for an organisation’s technological landscape.  Having a production-ready and automated setup helps you improve the customer experience and mitigate operational risks.

Consider this checklist before running production database workloads on Kubernetes:

High Availability

The database should be highly available, as this is usually pretty important for the organisation’s continuity. High Availability (HA) is a system characteristic that aims to ensure an agreed level of operational performance, typically uptime, during a standard period. Therefore, the right design and implementation of HA is critical for organisations and should be a key focus area.

In order to consider a database production-ready, it must also have a strategy for achieving a defined Recovery Point Objective (RPO) and  Recovery Time Objective (RTO). Such strategy should include automatic failover without data loss with switching traffic from old primary to new primary, automation of a one-member and full-cluster crash recovery, cross-region and/or cross-cluster replication, health and readiness checks, etc.

Security

A database can hold confidential, sensitive, or protected information, making it a prime target for cyberattacks. Therefore, the basic security requirement such as user authentication and authorisation is essential and should be enabled by default. In addition, semi-automatic updates, network security, encryption in transit and encryption at rest can be implemented.

Deployment Readiness

Deployment readiness is also vital for database production. There are multiple considerations here: schema setup, vertical and horizontal scalability, ability to deploy offline, database plugins, customisation and configuration of the database, various versions support, local storage support and many more. Learn more by watching  Mykola’s talk.

Backup  and Restore

This section was not mentioned in the talk but is very important for any production database cluster to implement backup and restore. Here is the list to consider:

• Backup to another region
• Backup compression
• Backup encryption with external encryption key storing
• Partial restoration
• Consistent backup of multi-shard clusters
• Point-in-Time Recovery – Possibility to make recovery to any transaction

Monitoring

A production database should be monitored appropriately. This can be implemented by having logs, query analytics, host and database metrics. In addition, appropriate alerting rules and notification channels must be in place.

Canonical charmed database operator

Canonical develops multiple open-source operators so developers can confidently and efficiently run databases on Kubernetes in a production environment. These products are featured on Charmhub.io. Canonical also offers two CNCF-certified Kubernetes distributions: Charmed Kubernetes and MicroK8s, which help simplify and accelerate the deployment of Kubernetes.

Conclusion

Running database clusters in public, private and hybrid environments gives you multiple benefits. Kubernetes provides the additional advantages of portability, no vendor lock-in, DevOps friendliness, scalability and cost-effectiveness.

If you want to delve deeper into this topic, watch Mykola’s talk on YouTube.