The Multi-Tenancy Spectrum
Understanding where vCluster fits requires comparing it against the full range of options:
| Approach | Isolation Level | CRD Support | Cost | Complexity |
|---|---|---|---|---|
| Namespaces + RBAC | Low (soft) | ❌ No | Very Low | Low |
| Namespaces + NetworkPolicy + OPA | Medium | ❌ No | Low | High |
| vCluster | High (control plane) | ✅ Yes | Low | Medium |
| Cluster API (real clusters) | Full | ✅ Yes | High | High |
| Managed clusters (EKS/GKE) | Full | ✅ Yes | Very High | Medium |
vCluster vs. Namespace Isolation
Namespace isolation with tools like OPA/Gatekeeper can enforce strong policies, but it cannot solve the CRD problem or provide API server isolation. vCluster solves both. The trade-off is slightly more operational complexity (managing vCluster lifecycle) and a small additional resource overhead for the control plane pod.
vCluster vs. Real Clusters (Cluster API)
Cluster API provisions actual Kubernetes clusters with dedicated worker nodes. This provides full compute isolation — a noisy tenant cannot consume another tenant's node resources. vCluster does not provide this: workloads from all virtual clusters share the same host nodes and are subject to the host's resource quotas. For regulated workloads requiring hard compute isolation (PCI-DSS, HIPAA), real clusters may be required. For developer environments and CI, vCluster's cost advantage is decisive.
The Syncer Configuration Trade-off
By default, vCluster syncs a conservative set of resources. You can extend the Syncer to also sync Ingresses, StorageClasses, or even custom resources — but each additional synced resource type increases coupling between the virtual and host cluster. A well-designed vCluster deployment keeps the sync surface minimal.