Nested Kubernetes with Loft


Domains, Clusters, and Isolation

The main purpose of Loft is, of course, strict isolation of the setups of different customers, and that is ultimately also Loft's unique selling point. After setting up Loft itself and connecting it to an existing Kubernetes cluster, the next step is to connect a user management system to Loft. As described, you have several options.

The simplest option is to maintain the users in Loft itself. The solution provides the required functionality and can manage a local user database. In companies with a central user directory, however, this kind of approach is unlikely to meet with approval and violates the principle of a single source of truth with regard to user data.

Fortunately, Loft can also be tied in with existing solutions such as an LDAP directory. The user data then comes directly from the directory, eliminating the need for a local user database in Loft. As a complement, the login can also be managed by the SSO service, which in fact is equivalent to disabling the password-based login in Loft.

Connecting Users and Clusters

Next comes the neuralgic moment in the interaction between Kubernetes and Loft. In Loft, you create a cluster account that gives a locally known user access to a Kubernetes cluster managed by Loft via Kiosk. Once you grant a local user access to a cluster, Loft tasks Kiosk with creating the appropriate namespace there and stores it as a virtual Kubernetes for deploying services.

Creating accounts does not have to be a manual task; the step can be automated with a template. Giving every employee in your company an account in every connected K8s cluster can be done with relatively little overhead. The highlight from the user's point of view is that the services can then be created transparently in the spaces built by Loft in exactly the same way as in a normal Kubernetes cluster. Loft takes care of all the logic behind the scenes with its little helper, Kiosk.

Virtual Clusters to the Rescue

If you have made it this far, Loft is almost ready for its intended use. At this point, all you have is a Loft space, which in Kubernetes is a namespace that comes with its own user management and largely behaves like genuine Kubernetes under the hood. The only thing missing for the end user is the Kubernetes APIs themselves.

A small tool from the Loft developers named vCluster comes into play here (Figure 4). vCluster is essentially based on the principle of rolling out a small but complete Kubernetes cluster into an existing Kubernetes, which gives you Kubernetes on Kubernetes.

Figure 4: vCluster is also from the Loft developers. The tool launches a virtual Kubernetes cluster in a Kubernetes cluster to conserve resources. ©Loft

Admittedly, this idea is not entirely new. For example, rolling out OpenStack on top of OpenStack to set up a test or staging environment is quite common. vCluster from Loft achieves the same thing for Kubernetes and bundles the components belonging to Kubernetes in such a way that they can run in a Kubernetes cluster themselves.

This arrangement has several major advantages from the administrator's perspective. First, a Kubernetes cluster rolled out this way is a real Kubernetes that is compatible with the K8s API and has official certification to prove it. It's not tinkering at all but a real K8s from an application perspective. Second, unlike the scenario described at the beginning, this setup doesn't need its own bare metal underpinnings. It uses the existing Kubernetes cluster along with its resources and rolls out the required components as pods. Because Kubernetes has long been able to roll out services redundantly, high availability is also not a problem.

Third, and this is also a big advantage of Loft, unlike classic Kubernetes, you do not have to set up namespaces and users manually. As I mentioned earlier, users can be integrated automatically for login purposes, and Loft takes care of implementing the desired permissions correctly in the target Kubernetes instances with its own permissions assignment afterwards. In practical terms, Loft implements the possibility for end users without an admin account in the Kubernetes target instances to put together their own real and complete K8s instances by pointing and clicking.

Buy this article as PDF

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

Buy ADMIN Magazine

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
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs

Support Our Work

ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.

Learn More”>


		<div class=