The Problem with Sharing
Think about a shared office building. Everyone uses the same lobby, elevators, and bathrooms. It's efficient, but you can't knock down walls or rewire the electricity — that would affect everyone else. Now imagine you need to run a jackhammer. You either do it quietly in your corner (and fail), or you rent your own building (expensive). Kubernetes has exactly this problem.
When a platform team needs to give multiple development teams access to Kubernetes, they face a fundamental tension between isolation and cost.
Shared vs. Dedicated
Option 1 — Namespaces (Soft Multi-tenancy): Give every team a Namespace in one giant shared cluster.
- Pros: Cheap, efficient resource usage. One control plane to manage.
- Cons: Severely restricted. Users cannot be
cluster-admin. They cannot install Custom Resource Definitions (CRDs) because CRDs are cluster-scoped globals — Team A installing Cert-Manager v1.0 breaks Team B who needs v2.0. If the shared API server goes down, every team goes down simultaneously. Noisy-neighbor problems on the API server are real.
Option 2 — Separate Clusters (Hard Multi-tenancy): Provision a dedicated cluster (EKS, GKE, AKS) for every team.
- Pros: Total isolation. Teams can be admins, install anything, and break things safely without affecting others.
- Cons: Prohibitively expensive. A managed Kubernetes control plane on AWS EKS costs roughly $70/month before you add a single worker node. At 50 teams, that's $3,500/month just for control planes sitting idle. Management overhead scales linearly.
The Third Option: Virtual Clusters
vCluster (by Loft Labs) is the middle ground. It lets you run fully functional Kubernetes clusters inside a Namespace of an existing Kubernetes cluster — the "Host Cluster."
Think of it like running a virtual machine inside a physical machine. The virtual machine believes it owns real hardware. The physical machine sees it as just another process. vCluster does the same trick for Kubernetes: to the tenant developer, it feels like a dedicated cluster with full admin rights. To the platform admin, it's just a StatefulSet running in a namespace.
This is sometimes called "Kubernetes Inception" — a cluster inside a cluster.