We're looking at multi-tenancy for a large Kubernetes environment across on-premises and cloud. Most teams can follow shared standards, but some need cluster-scoped access for operators or other workloads.
How well does vCluster fit that case in production? Do teams typically create and administer their own virtual clusters, or does a central team manage them?
The separate API server is the useful part for your operator problem. A team can have its own cluster-scoped resources, including CRDs and operator permissions, without getting equivalent cluster-wide access to the host.
That doesn't mean everything is isolated. Workloads, storage and networking still depend on the host environment. Check how the specific operator behaves and what it needs from the host before assuming virtual-cluster admin is enough.
Production is a reasonable use case to evaluate, not just development sandboxes. Monitoring stacks are another possible use. That said, the fact that a workload runs in a virtual cluster doesn't settle whether the isolation is sufficient for customer-facing workloads.
Start by defining the tenant boundary. Are these trusted internal teams, or can tenants run untrusted customer code? What access and isolation do they actually need? Those answers matter as much as the choice of control plane.
Self-service doesn't have to mean handing everyone host-cluster access. One model is an internal portal that starts a provisioning pipeline, with the central platform team controlling how virtual clusters are created. Teams can then get admin access inside their own virtual cluster, subject to the host's boundaries.
You'll still need to decide who owns upgrades, ongoing management and exceptions after provisioning. A creation workflow alone doesn't answer that.
u8!rom_462:
That distinction helps. We'd need to work out which responsibilities stay with the platform team after a virtual cluster is handed over.
For the cluster-scoped CRD and operator case, vCluster looks like a closer fit than Kamaji because the tenant gets a separate API server. I'd compare both against the actual workloads and management model, though, rather than treating either as a blanket isolation solution.
Answers are reviewed before publication.
Lornet.5:
Service meshes seem worth testing especially carefully. An operator that expects to control cluster-wide networking may not fit neatly inside that boundary.