Kubernetes Gets Back to Scaling with Virtual Clusters
PARIS — A virtual cluster — now that’s a way to imagine the next generation of virtualization.
But what is a virtual cluster? In this episode of The New Stack Makers, Loft Labs chief executive Lukas Gentele said that a virtual cluster is essentially a Kubernetes control plane that runs inside a container, which runs in another Kubernetes cluster. Loft Labs made its vcluster technology open source in 2021.
“That way, you don’t have to create 300 different control planes,” Gentele said. “Instead, you can run VMs in containers that are lighter, faster to spin and portable.”
Virtual clusters spin up in about six seconds, versus a real Kubernetes cluster. If you spin up a real K8s cluster in Amazon Elastic Kubernetes Service (EKS) or Google Kubernetes Engine (GKE), it takes 30 minutes or more to start, Gentele said.
Take Istio, the service mesh for the cloud native ecosystem. Let’s say you want to set up Istio for production. It will require multiple clusters and any number of control planes. A virtual cluster, Gentele said, may take one cluster, one Istio and 300 virtual clusters that share the same Istio as the real clusters.
A vCluster Integration with Rancher
At KubeCon + CloudNativeCon in Paris, Loft Labs announced it had integrated vCluster into Rancher, the container management and edge-computing platform. It allows users to manage virtual clusters in the same way they manage real clusters.
Loft Labs implemented Rancher following two years of community requests for virtual clusters. Loft Labs piloted Rancher at a company with a large Rancher footprint. The company faced problems that epitomized use cases for virtual clusters.
Internal engineers need a lot of clusters. And demand is enormous. New projects are coming out; projects are migrating to Kubernetes. In worst cases, multiple clusters are needed for the same application. There may be a staging cluster, a production cluster and a dev cluster for each application.
Let’s say a company has 500 applications. Now, you have thousands of clusters. These clusters are all separate from each other. So there have been attempts to fix the sharing matter through fleet management. However, in Gentele’s view, that is the wrong architecture.
“We believe it’s better to have a multitenant cluster instead of a single-tenant cluster so you can share things,” Gentele said.
In the early days of Kubernetes, he said, it was always about how many clusters or nodes could get packed in a cluster. Customers scaled up to 10,000 or more clusters.
Then something happened. Little three-node clusters started popping up. And that’s different from what Kubernetes creators designed it to do when they architected it to scale.
But because it’s super hard to share a cluster, and you have to set up many things to make it work, it could be more isolated. That’s why customers resort to these little single-tenant clusters instead of large multitenant clusters.
“And we’re essentially saying, hey, let’s do what Kubernetes is designed for,” Gentele said. “Let’s create a shared large cluster and have workflow clusters as a virtualization layer on top that actually allows you to do the sharing and security.”
