Kubernetes as an Alternative

Some system administrators might now claim that Kubernetes can hardly be the answer to Pacemaker's excessive complexity – and there is much truth in this; after all, Kubernetes has its own share of complexity. Although understandable, this argument falls short of the mark. Kubernetes undoubtedly offers a huge amount of functionality, but much of it is irrelevant for the vast majority of setups.

As in most cases where a piece of software starts life as something small and manageable but then expands to cover more and more use cases, the Pareto principle applies to Kubernetes: 80 percent of users would be very satisfied with 20 percent of Kubernetes' feature set (i.e., just the basic Kubernetes features).

That Kubernetes can be a genuine alternative, especially if you need a database, is demonstrated by the example described above from the Kubernetes point of view. Two servers are not enough; you need four, but not all of them have to be high-powered beasts with masses of CPU and RAM. Centralized components such as those that belong to Kubernetes can easily be bundled on virtual machines as an alternative. These virtual machines can run in a virtualization cluster that you might even already have in place and applies to the systems that will later run the containers – but you will want sufficient capacity in the form of vCPUs and vRAM.

Which Kubernetes?

The next step is the question as to which Kubernetes distribution to choose for your setup. Red Hat's OpenShift (Figure 4), SUSE's Rancher, and several other variants vie for your favor, but some caution is advised: A single admin with a manageable setup will rarely need OpenShift's feature set. On the downside, a full-blown OpenShift generates a mess of maintenance work, which is probably not worth the while for an SME in most cases.

Figure 4: Large Kubernetes distributions such as OpenShift offer massive feature sets, but in many cases they are not needed in an SME. © Red Hat

Instead, it is worth scouring the market for alternatives to major leauge solutions. One good candidate, especially for smaller environments, is MicroK8s [2] from Canonical, void of bells and whistles. Another option might be K3s [3], which claims to be an Internet of Things and edge variant of Kubernetes but still provides a full Kubernetes API and all the relevant functions. Even the upstream version of Kubernetes comes with a corresponding distribution named Minikube [4], which quickly sets up a simple Kubernetes cluster locally.

The decision as to which of these lean systems suits your use case is something you ultimately need to make yourself; again, your own preferences will play a role.

HA MySQL in a Jiff

In a database example, once a Kubernetes cluster is up and running, the remaining steps en route to a highly available MariaDB or MySQL database are quickly taken. The Kubernetes API offers a full set of functions, such as replica sets or stateful sets. In a setup with Galera (Figure 5), all that is missing is a suitable image with the required software, but this can be found on Docker Hub of good quality and with a traceable origin.

Figure 5: With a stateful set, Galera can easily be run in Kubernetes with a great deal of automation, offering quite significant advantages over a legacy approach.

The rest is quickly accomplished. If you want to extend Kubernetes to include a MariaDB instance with Galera using a stateful set, you then create the matching pod definitions as a YAML file and load them into your cluster. A few seconds later, you have a highly available, scalable database with persistent storage. What's more, Kubernetes will actively take care of database operations and replace failed pods with new ones if a piece of hardware bites the dust.

All told, this kind of setup is easier to create on a conventional Linux distribution than a legacy setup, and it offers improved functionality once in place – and it is true not just for MariaDB. After all, once Kubernetes has been set up, you have the option of running other services for which you previously used in-house hardware. What this means is that Kubernetes genuinely lets SMEs consolidate their in-house server farm. As a result, having less bare metal that needs to be maintained individually is a good thing because it saves you time.