Nested Kubernetes with Loft

Matryoshka

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

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Kubernetes containers, fleet management, and applications
    Kubernetes is all the rage, but many admins find themselves struggling to get started. We present the basic architecture and the most important components and terms.
  • Correctly integrating containers
    If you run microservices in containers, they are forced to communicate with each other – and with the outside world. We explain how to network pods and nodes in Kubernetes.
  • Linking Kubernetes clusters
    When Kubernetes needs to scale applications, it searches for free nodes that meet a container's CPU and main memory requirements; however, when the existing hardware is at full capacity, the Kubernetes Cluster Federation project (KubeFed) takes the pain out of adding clusters.
  • Five Kubernetes alternatives
    Many admins consider Kubernetes the obvious choice for managing containers; however, don't ignore the highly efficient alternatives just because they are less prominent.
  • VMware connections to the Kubernetes market
    VMware Tanzu comprises several tools and services that make it easy to build, run, and manage a Kubernetes environment from a single point of control.
comments powered by Disqus