I work at a large organization running more than 10,000 Kubernetes nodes across roughly 500 clusters in our own data centers, AWS, and Azure. We are trying to enforce consistent platform standards, but some teams have requirements that do not fit neatly within namespace-level access. The biggest issue is that certain workloads, especially those managed by operators, require cluster-scoped resources such as CRDs, roles, and namespaces.
We are evaluating Kamaji and vCluster as possible solutions. I am researching vCluster while a colleague looks into Kamaji, and I would like to hear from people with hands-on experience:
1. Are you using vCluster in production, or mainly for development and testing?
2. Does the platform team provision vClusters, or can application teams create them through self-service?
3. Who manages the vClusters after they are created? Do teams receive cluster-admin privileges inside their vCluster, and what host-level controls do you retain?
The potential use cases include production and customer-facing workloads, although we would continue to reserve dedicated physical clusters for teams that need substantial capacity or stronger isolation. Our main goal is to let teams install and manage their own operators without requiring the central platform team to support every possible operator combination.
4 Answers
vCluster is designed for this particular problem: each tenant gets a separate virtual API server and control plane, so its CRDs, RBAC objects, and operators can be installed without changing the host cluster. In many organizations, platform administrators manage the templates, quotas, upgrades, backups, and allowed integrations, while teams create their own environments through a self-service workflow.
Giving users cluster-admin inside their vCluster is common, especially outside production. The host cluster still needs strong policies for quotas, scheduling, storage, networking, and which resources are synchronized. For production, many teams keep the platform-managed configuration locked down while allowing application teams to choose their Kubernetes version or install approved tooling.
Roughly half of the organizations I have seen using vCluster have production workloads, including regulated environments. Many started with development or test environments before expanding into production, but the suitability depends heavily on the required isolation boundary and the kinds of workloads being run.
We run around 60 vClusters in production for several use cases. They began as development sandboxes, but operations teams now use them for some monitoring workloads as well.
Teams provision them through an internal portal that starts a controlled pipeline, so they never need direct access to the host cluster. We apply security policies during provisioning, then give the team admin rights inside the vCluster while keeping the host namespace tightly restricted. That gives them freedom to install operators and cluster-scoped resources within their own control plane without granting host-cluster administration.
The important limitation is that this is not complete infrastructure isolation. Workloads still consume host resources, and components involving networking, storage, scheduling, or node-level access need separate controls. We use host quotas and an allowlist for resources synchronized between the virtual and host clusters.
That operator use case is exactly what interests us. Managing every operator centrally becomes extremely difficult at our scale, and a pipeline-based self-service model is probably the direction we would take.
I would be careful with workloads such as service meshes or node-level networking operators. An admin inside the vCluster does not automatically mean the tenant is isolated from the host’s resource and networking behavior.
Before adding another control plane, it is worth checking whether a more granular RBAC model can solve most of the problem. You can often provide read and operational permissions through aggregated roles while withholding the ability to modify sensitive cluster-scoped resources. A platform-managed set of supported operators may also be simpler to support consistently across production and non-production.
The downside is that this leaves the platform team responsible for onboarding and maintaining every operator. vCluster is more compelling when teams genuinely need independent CRDs and operator lifecycles, and when the organization accepts the additional upgrade, backup, observability, and policy-management burden.
That is the dilemma we keep running into. A curated operator catalog works for common cases, but the long tail becomes a significant platform workload. We are considering vCluster mainly to give teams controlled autonomy without exposing the real cluster’s control plane.
There is a real tradeoff here. vCluster solves the control-plane and cluster-scoped-RBAC problem, but it adds another layer that the platform team must operate. In shared-node mode, a tenant can still consume excessive CPU or memory, overload parts of the host control plane, or create difficult storage and networking behavior. Virtual nodes do not provide the same isolation as dedicated worker nodes.
For stronger boundaries, private-node or dedicated-cluster arrangements may be necessary, but those increase cost and operational overhead. I would treat shared vClusters as a strong option for development, CI, and selected production workloads—not as an automatic replacement for dedicated clusters where tenants run untrusted code or need hard isolation.
Kamaji may be a better fit when the primary requirement is separate control planes with more conventional cluster administration, but it does not necessarily address the same self-service, bring-your-own-control-plane use case.
That distinction is important: shared vCluster nodes are primarily a control-plane abstraction, not a guarantee that tenants cannot affect shared worker capacity. Host-level quotas and admission policies are still essential.
Our tenant boundary is usually a namespace, except for teams needing dedicated capacity or unusually strong isolation. The main gap is teams that need cluster-scoped access for operators, while still being subject to our security scanning and production controls.