Loft Labs is the leading provider of platform engineering building blocks. Loft Labs delivers Kubernetes-native tools, functionality and frameworks purpose-built for platform engineers to manage, activate and optimize their platform stack. Loft Labs empowers platform teams at 100+ enterprises globally to harmonize engineering velocity and operational stability, and to build and run digital platforms at scale. To learn more about Loft Labs, visit www.loft.sh.
Virtual clusters are fully working Kubernetes clusters that run on top of other Kubernetes clusters. Compared to fully separate “real” clusters, virtual clusters reuse worker nodes and networking of the host cluster. They have their own control plane and schedule all workloads into a single namespace of the host cluster. Like virtual machines, virtual clusters partition a single physical cluster into multiple separate ones.
vClusters provide immense benefits for large-scale Kubernetes deployments and multi-tenancy.
Full Admin Access:
Deploy operators with CRDs, create namespaces and other cluster-scoped resources that you normally can’t create inside a namespace. Taint and label nodes without influencing the host cluster. See Nodes and Pod Scheduling for more information. Reuse and share services across multiple virtual clusters with ease.
Cost Savings:
Create lightweight vClusters that share the underlying host cluster instead of creating separate “real” clusters. Auto-scale, purge, snapshot, and move your vClusters, since they are Kubernetes deployments.
Low Overhead:
vClusters are super lightweight and only reside in a single namespace.
vClusters run with K3s, a super low-footprint K8s distribution. You can use other supported distributions such as K0s, vanilla Kubernetes, and AWS EKS.
The vCluster control plane runs inside a single pod. Open source vCluster also uses a CoreDNS pod for vCluster-internal DNS capabilities. With vCluster.Pro, however, you can enable the integrated CoreDNS so you don’t need the additional pod.
No Network Degradation:
Since the pods and services inside a vCluster are actually being synchronized down to the host cluster, they are effectively using the underlying cluster’s pod and service networking. The vCluster pods are as fast as other pods in the underlying host cluster.
API Server Compatibility:
vClusters run with the API server from the Kubernetes distribution that you choose to use. This ensures 100% Kubernetes API server compliance. vCluster manages its API server, controller-manager, and a separate, isolated data store. Use the embedded SQLite or a full-blown etcd if that’s what you need. See Persisting vCluster data for a list of supported data stores.
Security:
vCluster users need fewer permissions in the underlying host cluster / host namespace.
vCluster users can manage their own CRDs independently and can even modify RBAC inside their own vClusters.
vClusters provide an extra layer of isolation. Each vCluster manages its own API server and control plane, which means that fewer requests to the underlying cluster need to be secured.
Scalability:
Less pressure / fewer requests on the K8s API server in a large-scale cluster.
Higher scalability of clusters via cluster sharding / API server sharding into smaller vClusters.
No need for cluster admins to worry about conflicting CRDs or CRD versions with a growing number of users and deployments.