By Sebastian Bünker and by Matthias Grawinkel
While we’ve all seen our fair share of infrastructure technology to help us automate deployment, scaling, and management—from the classic VMware to open source tools such as OpenStack—there’s rarely been such a speedy and widespread adoption of one as with Kubernetes. And we think it has spread for a reason. Kubernetes makes it easier and breezier than ever to handle the complex IT infrastructure required to run all kinds of business-critical applications. So, we’re chiming in with all the swooning over Kubernetes—but add a storage twist.
Moving from Stateless to Persistent in Kubernetes
Storage is a concern that only comes into people’s focus once they have handled all the rest—networking, security, and so on. But once Kubernetes is to go into production, the storage question becomes pressing and essential: How do I persistently store my containers’ data? Data is, after all, the lifeblood of most any business application. So, unless you have a proper storage solution in place, the usefulness of containers is limited.
This post is about one way to answer the question on how to manage data for stateful applications. And, we’d claim, it’s the most forward-looking and, eventually the easiest way to set up and run a storage infrastructure for Kubernetes. Instead of talking about it, let’s jump right in and have a look at how easy it is to set up a modern storage environment for a Kubernetes cluster.
3-Step Storage Setup for Kubernetes
There are really just three broad steps to your fully featured installation. Given that you have a Kubernetes cluster up and running, just do the following:
Step 1: Deploy a next-generation data center file system operator and fill in the config file. Start with entering which services should be running on which hosts. Then choose the nodes that should run the data service, the metadata service, and the registry. The registry node will be an ephemeral bootstrap registry; its purpose is to get the system started. Once finished, the Operator will do its automagic.
Step 2: Tell Kubernetes to apply the operator config. The initial node starts said ephemeral bootstrap registry and also the API and the storage system console. Once it’s done, log into the bootstrap registry, check that all metadata and data services are registering and that they’re showing unformatted devices. Choose three nodes and format their registry devices; the registry pods will then start and create a replicated cluster. As soon as the two other registries are online, it’s safe to shut down and delete the ephemeral bootstrap node—since by now, the registry service is persisted to the disks we had chosen before.
Step 3: Format the data and metadata devices by using the web console. Then go ahead and create volumes or set up storage classes for dynamic volume provisioning. When done, the storage cluster is ready to use and you can deploy application pods that use these volumes. You can do so on any nodes where the Operator started a client pod.
Those were a lot of words, but the actual process is quite simple and straightforward and, thanks to the recently introduced Kubernetes Operator framework, greatly reduces the complexity that comes with interdependent infrastructure deployments and management.
About the Authors:
Sebastian Bünker is working on product marketing at Quobyte. He also does some coding for the web. And he knows first-hand about split-brain problems, being a philosopher by training and a marketer/coder by trade. Matthias Grawinkel is a software engineer for Quobyte, with interests in distributed storage and database systems, DevOps and datacenter automation.
