Managing Cloud Native Data on Kubernetes

Chapter 4. Automating Database Deployment on Kubernetes with Helm

In the previous chapter, you learned how to deploy both single-node and multinode databases on Kubernetes by hand, creating one element at a time. We did things the “hard way” on purpose to help maximize your understanding of using Kubernetes primitives to set up the compute, network, and storage resources that a database requires. Of course, this doesn’t represent the experience of running databases in production on Kubernetes, for a couple of reasons.

First, teams typically don’t deploy databases by hand, one YAML file at a time. That can get pretty tedious. And even combining the configurations into a single file could start to get pretty complicated, especially for more sophisticated deployments. Consider the increase in the amount of configuration required in Chapter 3 for Cassandra as a multinode database compared with the single-node MySQL deployment. This won’t scale for large enterprises.

Second, while deploying a database is great, what about keeping it running over time? You need your data infrastructure to remain reliable and performant over the long haul, and data infrastructure is known for requiring a lot of care and feeding. Put another way, the task of running a system is often divided into “day one” (the joyous day when you deploy an application to production) and “day two” (every day after the first, when you need to operate and evolve your application while maintaining high availability).

These ...