How Loft Interacts

Most of the multitenancy that Loft retrofits on the basis of Kubernetes namespaces initially exists in its own API, which raises the question of how the commands from Loft services then become Kubernetes commands and, ultimately, provide rolled-out pods. To achieve this goal, Loft developers provide the connected Kubernetes clusters a minder named Kiosk. Officially, Kiosk is an extension for Kubernetes that teaches it multitenancy.

What sounds theoretical is actually quite simple in practice: Kiosk is responsible for managing the namespaces on the Kubernetes side and connecting them to the details originating from Loft itself. However, you again have to deal with the different nomenclature. Although the documentation for Loft and Kiosk refers to "spaces," it does not mean the same thing as "namespaces" in Kubernetes. Instead, a space is a virtual namespace. For Loft users, it looks like bona fide Kubernetes from the outside, but on the back end it is just a namespace in Kubernetes with the additional features from Loft.

Loft Workflow

Loft is complex; therefore, from the admin's point of view, it makes sense to visualize the Loft workflow and the individual commands it contains with a concrete example.

In the typical style of Kubernetes, the Loft installation itself is not that complex. The required services come in the form of ready-made containers that can be rolled out in Kubernetes in a fraction of a second. All you have to do is specify whether the cluster you want to use for running Loft should also be the one in which the Loft namespaces are stored later. However, if your budget is big enough, you would do well to run a trunk Kubernetes for the Loft components and maintain a clear separation of responsibilities.

Once Loft itself is running, the next step is to connect Kubernetes (i.e., the Kubernetes cluster in which the virtual K8s environments are to be created). Loft makes this an easy task: Connecting with an existing API in a Kubernetes cluster is a quick and easy experience in the Loft user interface. If you prefer to use the command line, you can achieve the same effect with just a few kubectl commands.

Shared Services

To the Loft developers, it is clearly important to cover as many fields of application for Kubernetes as possible with their product. They have designed Loft to graft multitenancy onto Kubernetes, but they do not lose sight of the gray areas between "one Kubernetes per customer" and "strictly separated namespaces for all customers."

The shared services in Loft are an example: If you have services that need to be available to all connected customers in an environment, they can be implemented as shared services. As an example, the developers cite a Certbot that creates SSL certificates under a standard domain for various services on demand. Both the necessary subdomain and the service itself can be created directly in Loft (Figure 3).

Figure 3: Although the Loft clusters are strictly isolated from each other, shared services can still be set up. ©Loft