Managing Cloud Native Data on Kubernetes

Chapter 3. Databases on Kubernetes the Hard Way

As we discussed in Chapter 1, Kubernetes was designed for stateless workloads. A corollary to this is that stateless workloads are what Kubernetes does best. Because of this, some have argued that you shouldn’t try to run stateful workloads on Kubernetes, and you may hear various recommendations about what you should do instead: “Use a managed service,” or “Leave data in legacy databases in your on-premises datacenter,” or perhaps even “Run your databases in the cloud, but in traditional VMs instead of containers.”

While these recommendations are still viable options, one of our main goals in this book is to demonstrate that running data infrastructure in Kubernetes has become not only a viable option, but a preferred option. In his article “A Case for Databases on Kubernetes from a Former Skeptic”, Christopher Bradford describes his journey from being skeptical of running any stateful workload in Kubernetes, to grudging acceptance of running data infrastructure on Kubernetes for development and test workloads, to enthusiastic evangelism around deploying databases on Kubernetes in production. This journey is typical of many in the Data on Kubernetes Community (DoKC). By the middle of 2020, Boris Kurktchiev was able to cite a growing consensus that managing stateful workloads on Kubernetes had reached a point of viability, and even maturity, in his article “3 Reasons to Bring Stateful Applications to Kubernetes”.

How did this change ...