Loft Labs Better Isolates Virtual Kubernetes Clusters
Loft Labs has added an isolation capability to its open source virtual cluster software that enables multiple application workloads to more easily share the same Kubernetes cluster.
Lukas Gentele, Loft Labs CEO, says this addition to vcluster reduces the time and effort required to isolate workloads running within a multi-tenant Kubernetes environment. Each virtual cluster can now be configured to have its own separate control plane to ensure isolation, notes Gentele.
Previously, any Kubernetes security mechanisms for vcluster workloads had to be created manually by cluster administrators. Now, a variety of Kubernetes security controls can be automatically configured without the need for manual configuration, including admission control policies, resource quotas and limit ranges and network policies. Over time, Gentele says, Loft Labs expects most IT teams deploying virtual clusters will standardize on logical isolation of vclusters.
The isolation mode enforces a set of baseline policies; however, administrators can further harden virtual clusters via their own custom policies. That capability will make it simpler for IT teams to enforce zero-trust IT policies across a multi-tenant Kubernetes cluster, notes Gentele.
Loft Labs claims vcluster has now been downloaded more than 50,000 times. Vcluster enables users to create lightweight Kubernetes clusters that run inside the namespaces of a multi-tenant cluster. A virtual cluster behaves just like any certified distribution of Kubernetes, which means that it passes all conformance tests required by the Cloud Native Computing Foundation (CNCF). A vcluster can be spun up using either a graphical tool or via the Loft command line interface (CLI) or, alternatively, by using the kubectl CLI that comes with Kubernetes.
The company also provides an enterprise-grade platform on top of vcluster—dubbed Loft—that IT teams can use to enable developers, engineers or IT administrators self-service provisioning of Kubernetes clusters as required. Those virtual clusters are often used as development environments when engineers are building, testing and debugging cloud-native software in addition to providing an ephemeral environment for executing continuous integration/continuous delivery (CI/CD) pipelines. The overarching goal is to make it simpler for developers to spin up logically separated instances of Kubernetes that can scale up and down on a server or in the cloud rather than being limited to the resources available on an individual desktop or laptop system.
It’s still early days as far as virtualization of Kubernetes clusters is concerned. As the number of Kubernetes clusters deployed in IT environments continues to increase, finding a way to manage them more efficiently will become a higher priority. The issue many IT organizations will need to resolve is how to address this problem before Kubernetes cluster sprawl gets any more out of control. A vcluster makes it simpler to provision—and, just as importantly, tear down—a Kubernetes cluster at various stages of an application development project.
As attractive as that capability may be, however, most organizations are not going to be allowed to employ them widely until they pass muster with cybersecurity teams. Those teams are increasingly scrutinizing the entire software supply chain in the wake of a series of high-profile security breaches.
