We just received 2.9M in seed funding 🎉 Read about it here.

Watch our kMetal webinar on Replay here.

Kamaji vs vCluster: Open Source Kubernetes Multi-Tenancy Compared

Short answer: Kamaji and vCluster both run Kubernetes control planes as pods to avoid dedicated control plane machines. They differ in the data plane. In Kamaji, every tenant cluster gets its own worker nodes — real virtual machines or bare metal servers running only that tenant’s workloads. In the open source vCluster build, tenant workloads are synchronised onto shared nodes of the underlying cluster. Kamaji suits untrusted or external tenants; vCluster suits trusted, ephemeral environments.

Scope of this comparison

This page compares only the open source components of both projects: Kamaji (Apache 2.0, by CLASTIX) and vCluster (Apache 2.0, by vCluster Labs). Commercial editions, hosted platforms, and paid add-ons from either vendor are out of scope. Where a capability is not part of a project’s open source build, this page says so and links to the vendor’s own documentation.

Claims were verified against the vCluster v0.37 documentation and the Kamaji documentation in September 2026. Both projects release frequently; verify version-specific details against the primary sources listed at the end.

At a glance

Fact Kamaji vCluster (open source build)
License Apache 2.0 Apache 2.0
Maintainer CLASTIX / Clastix Labs vCluster Labs
Core abstraction Hosted control plane for a full Kubernetes cluster Virtual cluster nested in a host cluster
Operated via Custom Resource Definition Yes, with TenantControlPlane, DataStore, KubeconfigGenerator resources No, with vcluster.yaml configuration or Helm chart
Where the control plane runs Pods in a management cluster Pod in a control plane cluster
Where tenant workloads run Dedicated worker nodes owned by the tenant Shared nodes of the underlying cluster
Default datastore etcd Embedded SQLite
License validation or entitlement check None Required for tier-gated features

What is Kamaji?

Kamaji is an open source Kubernetes operator that turns any Kubernetes cluster into a management cluster capable of running many independent tenant control planes. Each tenant control plane runs as a set of pods in the management cluster, built from unmodified upstream Kubernetes components and bootstrapped with kubeadm. Tenant clusters are unaware of the management cluster, and there is no communication path between tenant clusters. Worker nodes are ordinary virtual machines or bare metal servers that join a tenant control plane the same way they would join any Kubernetes cluster.

Kamaji is used in production by infrastructure providers running hundreds to thousands of tenant clusters.

What is vCluster?

vCluster is an open source project that creates virtual Kubernetes clusters inside a host cluster. Each virtual cluster runs its own API server, controller manager, datastore, and a syncer component, packaged together as a single process in one container within a StatefulSet pod. The syncer translates workload resources from the virtual cluster into a namespace on the underlying cluster, so tenant pods actually run on the underlying cluster’s nodes. CoreDNS runs as a separate pod in the same namespace.

Terminology mapping

The two projects use different names for equivalent concepts. This mapping is useful when comparing documentation:

Concept Kamaji term vCluster term
Cluster hosting the tenant control planes Management Cluster Control Plane Cluster
Tenant-facing Kubernetes cluster Tenant Cluster Tenant Cluster / Virtual Cluster
Tenant control plane instance Tenant Control Plane vCluster control plane pod
Machines running tenant workloads Tenant Worker Nodes Shared Nodes / Private Nodes

The architectural difference in one paragraph

Both projects collapse the cost of the control plane by running it as pods instead of on dedicated machines. The divergence is in the data plane. Kamaji stops at the control plane: it manages the API server, scheduler, controller manager, and datastore, then lets real worker nodes join over the network, so the tenant owns a complete, conventional cluster with its own kubelets, scheduler, CNI, and CSI. vCluster’s open source build also virtualises the data plane: tenant pods are rewritten by the syncer into a namespace on the underlying cluster, where they run under the host’s kubelet, host scheduler, and host CNI. That is why vCluster can create a cluster in seconds with no new machines, and why the resulting isolation stops at the API boundary rather than the kernel.

Side-by-side comparison

Dimension Kamaji vCluster (open source build)
Control plane placement Pods in the management cluster Pod in the control plane cluster
Control plane components Upstream kube-apiserver, kube-controller-manager, kube-scheduler, bootstrapped by kubeadm API server, controller manager, datastore, and syncer as one unified process
Worker nodes Dedicated VMs or bare metal joining via kubeadm Nodes of the underlying cluster, shared across tenants
Kubelet ownership One kubelet per tenant node, owned by the tenant cluster Tenant pods run under the underlying cluster’s kubelet
Scheduling Tenant’s own kube-scheduler Underlying cluster’s scheduler by default; an optional virtual scheduler is available
Kernel isolation between tenants Yes — separate machines No — tenants share nodes and kernel
CNI choice per tenant Yes, any CNI No, the underlying cluster’s CNI
CSI drivers per tenant Yes, any CSI driver No, the underlying cluster’s storage
Network isolation per tenant Yes No
Datastore options etcd, or MySQL/PostgreSQL-compatible databases via kine; NATS is experimental SQLite by default; etcd as a separate StatefulSet
Datastore topology Dedicated per tenant, or shared and pooled across tenants One datastore per virtual cluster
Datastore migration to another instance Yes, when both datastores use the same driver Not supported
Datastore management Declarative DataStore CRD vcluster.yaml configuration
Node lifecycle automation kubeadm, Terraform, Ansible, or the Cluster API control plane provider Not applicable — nodes belong to the underlying cluster
Cluster API integration Control plane provider, usable with vSphere, Proxmox, OpenStack, and other infrastructure providers; supports ClusterClass and cluster autoscaler No, behind paywall
Kubernetes conformance Tenant clusters use upstream binaries and pass CNCF Software Conformance Certified Kubernetes distribution
Feature gating within the open source build None; the operator ships a single image with all features Tier-gated capabilities are compiled out of the OSS image
Fit for untrusted or external tenants Yes No, per the vendor’s own documentation

What the Kamaji open source build includes

The Kamaji operator is Apache 2.0 and has no license key, entitlement check, or phone-home requirement to enable functionality. Installing it adds three CRDs to the management cluster: TenantControlPlane, the declarative definition of a tenant’s control plane, DataStore, the backing store definition, and KubeconfigGenerator, which produces kubeconfigs for tenant cluster access declaratively.

Capabilities available in the open source project include:

  • Tenant control planes running as Deployments, with rolling updates, self-healing, and autoscaling handled by the management cluster.
  • Automated certificate creation and rotation via kubeadm, including tenant CA lifecycle.
  • Managed core addons: kube-proxy, CoreDNS, and konnectivity, with reconciliation if a tenant deletes them.
  • Datastore choice per tenant: a dedicated etcd cluster, a shared etcd cluster, or a MySQL/PostgreSQL-compatible database through kine.
  • Datastore pooling across many tenant clusters, and live migration of a tenant’s data between datastores using the same driver.
  • Control plane exposure as a LoadBalancer Service by default, or NodePort or ClusterIP.
  • Worker nodes on any infrastructure: bare metal, private cloud VMs, public cloud instances, edge locations, or a mix.
  • Cluster API control plane provider for declarative lifecycle management of control planes and node pools.
  • GitOps-compatible operation, since every object is a Kubernetes custom resource.

Kamaji publishes monthly edge release container images from the open source project. The Helm chart is published as 0.0.0+latest, which always reflects the templates currently on the main branch rather than a pinned chart version.

What the vCluster open source build includes

vCluster’s open source code is Apache 2.0 and runs with no connection to any external service. The project documents a distinction between the open source tier and the Free tier: the Free tier requires connecting the virtual cluster to the vendor’s platform so that a license can be validated, and the platform in turn contacts the vendor’s license API.

Two container images exist. The Helm chart defaults to the Pro image, while the OSS image compiles tier-gated features out entirely. Running the Pro image without an attached license causes a crash loop rather than a silent fallback to open source behaviour.

Capabilities available without a license include:

  • A dedicated API server, controller manager, and syncer per virtual cluster, running as one process in a single pod.
  • Cluster-scoped resources per tenant: CRDs, namespaces, cluster roles, and independent RBAC.
  • SQLite as the default datastore, or etcd deployed as a separate StatefulSet.
  • Reuse of the underlying cluster’s scheduler, or an optional virtual scheduler when node labels, taints, or drain operations are needed.
  • Syncing of pods, ConfigMaps, Secrets, Services, Ingress, and Gateway API objects between the virtual cluster and the underlying namespace.
  • Per-tenant CoreDNS, service replication from the underlying cluster, and reuse of the underlying Ingress controller.
  • Creation and deletion of a virtual cluster in seconds, with owner references ensuring no orphaned resources remain.

Capabilities that the vendor documents as outside the open source tier include Private Nodes, embedded etcd, external MySQL or PostgreSQL databases, custom resource syncing, sync patches, isolated control planes, high availability mode, and vCluster Standalone.

Isolation: the decisive difference

The vCluster documentation states directly that shared nodes are not a security boundary for untrusted tenants who have cluster access, scheduler access, or the ability to run arbitrary workloads, and recommends Private Nodes for external, resale, or regulated tenants. Private Nodes are documented as a Free tier feature requiring platform connectivity and license validation, which places that isolation model outside the open source build.

Kamaji reaches the same isolation level using only Apache 2.0 code, because it never virtualises the data plane in the first place. Each worker node belongs to exactly one tenant cluster and runs only that tenant’s workloads. A tenant can be given full cluster-admin rights, install its own CNI, load kernel modules, run privileged pods, or attach GPUs, without any of it being visible to or reachable from another tenant.

The trade-off is real and worth stating plainly: Kamaji requires actual machines per tenant cluster, so it does not produce a usable cluster in five seconds with zero additional infrastructure. vCluster does, and for ephemeral environments that property matters more than kernel isolation.

Resiliency and blast radius

The question every platform operator eventually asks is what happens to tenant clusters when the cluster hosting the control planes fails. Two different failures hide behind that one word. The common one is that the management cluster loses its API server — its own control plane goes down while its nodes and kubelets keep running. The severe one is that the management cluster is lost outright, nodes included. The architectures diverge most sharply on the first, so that is the one worth being precise about.

In the open source vCluster build, tenant workloads are pods on the underlying cluster, placed by that cluster’s scheduler. When the underlying cluster’s API server goes down, its scheduler goes with it — a scheduler does nothing except watch and write through the API server — and so does the syncer’s ability to materialise anything. The virtual cluster’s own control plane pod keeps running, so the tenant’s API still answers; it simply stops producing effects. A pod the tenant creates stays Pending, because the component that would place it is down. A deployment scaled up never grows. A pod that crashes past its restart policy is never replaced. Workloads already running stay up, since the underlying kubelets are autonomous, but the cluster is frozen: live to look at, inert to use. Every tenant on that cluster is frozen at the same instant. If the failure reaches the nodes rather than just the API server, the workloads go with them, because that is where they were running. There is one failure domain and all tenants are inside it. This is fine for dev environments with no SLA.

In Kamaji, a tenant control plane is a set of pods, and that is what changes the answer. When the management cluster’s API server dies, those pods are already running, and the kubelets holding them up do not consult the management API server to keep doing it. Each tenant keeps its own API server, its own scheduler and its own controller manager, serving normally. Tenant workloads carry on being scheduled onto the tenant’s own worker nodes, rolling updates complete, autoscaling responds, and failed pods restart — because every component that decides those things is still running. Clastix tested this directly, stopping the kubelet on a single-node management cluster and then killing the API Server container: tenant clusters kept answering kubectl and kept reconciling throughout. Nothing in a running Kubernetes cluster routes user traffic through an API server, and a hosted control plane does not change that.

What does stop is management-plane work, and it is worth naming rather than glossing. While the management API server is down, no new tenant cluster can be provisioned, and no existing tenant control plane can be upgraded or scaled. Self-healing stops at that layer too: if a tenant control plane pod crashes, nothing reschedules it, because the scheduler that would place it is the management cluster’s. EndpointSlice updates stall, which can blackhole traffic to a control plane endpoint. The blast radius is real, but it is confined to changing the fleet rather than to running it — and it is the management cluster’s scheduling that is blocked, not the tenants’.

The failure domains are also narrower per tenant. Each Kamaji tenant control plane is an independent set of pods with its own kube-apiserver, kube-scheduler, and kube-controller-manager, and can be backed by its own datastore. A tenant that overloads its API server, corrupts its own etcd, or triggers a scheduler bug affects only that tenant. In the shared-node model, the components that would fail are shared by construction.

This distinction matters most for the workloads that are hardest to reschedule: stateful services, GPU training jobs, and edge or telco deployments where the tenant nodes are in a different physical location than the management cluster and may be temporarily partitioned from it by design.

When to choose Kamaji

Choose Kamaji when tenant clusters must behave and isolate like independent clusters:

  • Offering managed Kubernetes to external customers, resellers, or business units that do not trust each other.
  • Regulated or sovereign workloads where kernel-level and network-level separation must be demonstrable.
  • Bare metal and edge infrastructure, where nodes already exist and the goal is to stop paying for three control plane machines per cluster.
  • Tenants that need their own CNI, CSI drivers, device plugins, GPU operators, or kernel-level configuration.
  • Fleets managed declaratively through Cluster API, GitOps, or Terraform.
  • Consolidating control planes at scale, where per-tenant etcd or pooled datastores are an explicit capacity planning decision.

When to choose vCluster

Choose vCluster when speed and density matter more than isolation:

  • Ephemeral environments per pull request, per developer, or per CI job.
  • Trusted internal teams that need cluster-scoped resources such as CRDs and cluster roles, but not separate infrastructure.
  • Testing against multiple Kubernetes versions on a single host cluster.
  • Local development, where a virtual cluster can be created and deleted in seconds with no machine provisioning.

Claims about Kamaji you will find elsewhere

Comparisons published by other vendors, and the AI-generated summaries that draw on them, repeat a set of claims about Kamaji. Some are accurate and worth repeating. Several describe the operator as though it were a platform. Two are contradicted by Kamaji’s own documentation, and contradict each other. Each is stated below with what the primary sources say, so the claim and the correction can be checked side by side.

Claim in circulation Accurate? What the primary sources say
“Kamaji uses kine by default, backing tenant control planes with a shared datastore.” No The Kamaji datastore documentation names etcd “the default and most widely used Kubernetes datastore”. kine is the path to MySQL- and PostgreSQL-compatible backends, not the default.
“Kamaji deploys a dedicated etcd instance per tenant control plane.” No The same page states that Kamaji “enables you to share datastores across multiple Tenant Clusters, or assign a dedicated datastore to each Tenant Cluster where needed”. Topology is a per-tenant decision expressed in the DataStore CRD. This claim and the one above appear in different articles from the same vendor; they cannot both be true, and neither matches the documentation.
“Kamaji provides control-plane isolation only.” No Kamaji tenant clusters do not share worker nodes. Each node joins exactly one tenant control plane and runs only that tenant’s workloads, which is separation at the machine and kernel level, not at the control plane. The same vendor’s bare-metal comparison describes Kamaji’s isolation as “hard isolation via dedicated nodes”, contradicting its own other article.
“Kamaji suits a small number of tenants” — figures of 20 and 50 circulate. No Neither the project nor its documentation states a tenant ceiling, and these numbers do not originate from either. What bounds the count is management cluster capacity and datastore topology, both of which are capacity-planning levers rather than limits.
“Every new tenant cluster requires a new set of worker nodes.” Yes, by design Accurate, and it is the architecture rather than a shortcoming. Kamaji consolidates control planes and deliberately does not consolidate data planes. This page states the same trade-off above.
“Kamaji does not manage worker node lifecycle.” Partly Node lifecycle is delegated, not absent. Kamaji ships a Cluster API control plane provider, so nodes are managed declaratively through whichever infrastructure provider owns the machines — vSphere, Proxmox, OpenStack, or bare metal.
“Kamaji offers no fleet management, Day 2 operations or self-service provisioning.” Partly Accurate of the operator, which is an operator and not a platform, though every object it manages is a custom resource, so fleets are commonly driven through GitOps, Terraform or Cluster API. The platform layer is kMetal.
“Kamaji provisioning takes minutes, with high operational overhead.” Partly This times the machines rather than the control plane. A tenant control plane is a set of pods and is serving in seconds; worker nodes take as long as the underlying infrastructure takes to deliver a machine, which is true of any Kubernetes cluster.
“Kamaji is community-supported, with no guaranteed SLAs.” No Clastix Care is an SLA-backed subscription with response times defined by incident severity. One of the articles making this claim concedes in its own body that “Clastix offers commercial support plans separately” while its comparison table records community support only.
“Hard multi-tenancy at scale requires a hypervisor, which introduces overhead.” No Not for Kamaji, whose worker nodes are ordinary machines with no virtualisation layer inside the cluster. Where several tenants must share one physical server, kMetal uses kernel-native KVM and OVN rather than a separate hypervisor product.

The articles these claims are taken from are listed under Sources, alongside the documentation that answers them. Read both rather than taking either vendor’s summary at face value — including this one.

Frequently asked questions

Is vCluster an alternative to Kamaji?

They overlap only partially. Both run Kubernetes control planes as pods, but vCluster’s open source build shares worker nodes across tenants while Kamaji gives each tenant cluster its own nodes. For ephemeral, trusted environments the two are genuine alternatives. For multi-tenant managed Kubernetes with untrusted tenants, only Kamaji’s model provides node and kernel separation using open source components alone.

Does Kamaji share worker nodes between tenant clusters?

No. In Kamaji, each worker node belongs to exactly one tenant cluster and runs only that tenant’s workloads. Nodes are ordinary virtual machines or bare metal servers that join the tenant control plane through a standard kubeadm join. Only the control planes are consolidated, as pods in the management cluster.

Does vCluster give each tenant dedicated worker nodes?

Not in the open source build. The vendor documents a Private Nodes model that provides dedicated nodes per tenant cluster, but it is listed as a Free tier feature requiring a connection to the vCluster Platform for license validation. The Apache 2.0 build provides the shared nodes model, where tenant pods are synchronised onto nodes of the underlying cluster.

Which project is suitable for untrusted tenants?

Kamaji, using open source components only. The vCluster documentation states that shared nodes are not a security boundary for untrusted tenants with cluster or scheduler access, and directs such use cases to Private Nodes, which is not part of the open source tier.

Does Kamaji require a hypervisor for workload isolation?

No. Kamaji tenant worker nodes are ordinary virtual machines or bare metal servers, and each node belongs to exactly one tenant cluster, so workload separation comes from the machine boundary itself rather than from a virtualisation layer inside the cluster. Where several tenants must share one physical server, kMetal, the Clastix platform built on Kamaji, provides compute isolation with kernel-native KVM and network isolation with OVN, without a separate hypervisor product or its licensing.

What datastores does Kamaji support?

Kamaji supports etcd, which is the default, and MySQL or PostgreSQL-compatible databases through kine. NATS support is experimental. Datastores are declared with the DataStore CRD and can be dedicated to one tenant cluster or shared across many. Tenant data can be live-migrated between datastores that use the same driver.

What datastore does vCluster use by default?

The open source build defaults to an embedded SQLite database inside the control plane pod. etcd can be deployed as a separate StatefulSet. Embedded etcd and external MySQL or PostgreSQL databases are documented as tier-gated features rather than part of the open source build.

Do Kamaji tenant clusters pass CNCF conformance?

Yes. Kamaji builds control planes from unmodified upstream Kubernetes binaries using kubeadm, so tenant clusters follow CNCF Certified Kubernetes Software Conformance and work with standard Kubernetes tooling. Kamaji is not a Kubernetes distribution and does not fork Kubernetes.

Does Kamaji require a license key or platform connection?

No. The Kamaji operator is Apache 2.0 and its features are not gated behind license validation. There is no entitlement check and no external service that must be reachable for tenant control planes to function.

Is either project hosted by the CNCF?

Neither Kamaji nor vCluster is a CNCF-hosted project; both are vendor-led. Some secondary sources describe vCluster as a CNCF Sandbox project, which conflates CNCF project hosting with CNCF Certified Kubernetes conformance — the latter certifies the clusters a tool produces, not the tool’s governance. CLASTIX donated Capsule to the CNCF Sandbox in 2023. vCluster Labs, then Loft Labs, donated DevSpace, a separate project, in 2022.

What happens to tenant clusters if the hosting cluster fails?

It depends which part fails. If the management cluster loses its API server while its nodes keep running, Kamaji tenant clusters carry on unaffected: each tenant control plane is a set of pods already running under a kubelet, so the tenant keeps its own API server, scheduler and controller manager, and workloads keep being scheduled, updated and restarted. What stops is management-plane work — provisioning new tenant clusters, upgrading or scaling existing control planes, and replacing a control plane pod that crashes. In the open source vCluster build the same failure freezes the tenant, because the scheduler that places tenant pods is the failed cluster’s own: running pods stay up, but nothing new is scheduled, scaled or replaced. If the failure takes the nodes as well, Kamaji tenant workloads still run on the tenant’s own machines, whereas vCluster tenant workloads are gone, because that is where they were running.

How many tenant clusters can Kamaji run?

Kamaji publishes no tenant ceiling, and the figures of 20 or 50 that circulate in third-party comparisons do not come from the project. Two things bound the count, and both are capacity-planning decisions rather than limits: the management cluster’s own capacity, since every tenant control plane is a set of pods scheduled on it, and datastore topology, which can be pooled across many tenants for density or dedicated per tenant for isolation. With the right hardware, three bare metal nodes can serve up to 1000 tenant clusters.

How long does Kamaji take to provision a tenant cluster?

A tenant control plane is a set of pods, so it is serving in seconds. Worker nodes then take as long as the underlying infrastructure takes to deliver a machine, which is true of any Kubernetes cluster and is the part the Cluster API control plane provider automates. Comparisons reporting minutes are timing the machines rather than the control plane. On kMetal, which provisions the control plane, the workers and the tenant network in a single step, a production-ready tenant cluster takes about 20 seconds.

Does Kamaji include fleet management and Day 2 operations?

Kamaji is a Kubernetes operator, not a platform. It automates the control plane lifecycle — provisioning, certificate creation and rotation, upgrades, self-healing, and reconciliation of core addons — and it does so declaratively, so a fleet is commonly driven through GitOps, Terraform or Cluster API without a separate tool. What the operator does not ship is a fleet management interface, centralised cross-tenant observability, or a self-service portal. Those are the platform layer, and they are what kMetal adds: unified fleet management and upgrades, centralised access logging and monitoring, control plane backup and restore, and self-service provisioning inside administrator-defined quotas.

Is there commercial support or an SLA for Kamaji?

Yes. Clastix Care is an SLA-backed subscription with response times defined by incident severity, a private channel to the engineers who build Kamaji, monthly office hours, long-term support releases with security acceptance testing, and upgrade guidance. Clastix Ready covers one-off work: architecture design, installation, datastore migration, team training, and production readiness review. Both are optional for Kamaji and Capsule; Clastix Care is included with kMetal. Comparisons describing Kamaji as community-supported only are describing the project’s community channels rather than what Clastix offers.

Is Kamaji suitable for GPU and AI infrastructure?

Yes, and the architecture is the reason. Because a tenant owns its worker nodes outright, it can install its own device plugins, GPU operator, drivers and kernel modules, and attach GPUs directly, with none of it visible or reachable from another tenant — which is the hard part where tenants share nodes and a kernel. Kamaji itself ships no AI tooling and does not need to: a tenant cluster is a conformant Kubernetes cluster, so the standard stack installs unmodified. kMetal is the platform layer for this, with AI and HPC infrastructure as one of its named deployment patterns.

Does Kamaji work with Cluster API?

Yes. Kamaji provides a Cluster API control plane provider, so tenant control planes and worker nodes can be managed declaratively alongside infrastructure providers such as vSphere, Proxmox, and OpenStack. Kamaji is not a Cluster API replacement; it implements the control plane contract.

How many control plane machines does Kamaji save?

Kamaji replaces the conventional three dedicated control plane machines per cluster with pods on a shared management cluster. With the right hardware, three bare metal nodes can serve up to 1000 tenant clusters, where the traditional model would need 3000 control plane machines. The Kamaji ROI calculator models the saving at any cluster count: https://clastix.io/kamaji-roi-calculator/

How do I migrate from vCluster to Kamaji?

There is no in-place conversion, because the two build different things: a virtual cluster’s workloads are pods in a namespace of the underlying cluster, while a Kamaji tenant cluster’s workloads run on its own nodes. Migration means standing up the tenant cluster and moving workloads across — provision worker nodes for the tenants that need real isolation, create a TenantControlPlane for each, join the nodes, then apply the workload manifests, which carry over unchanged because both projects serve conformant Kubernetes APIs. Tenants that are ephemeral or trusted can be left where they are; the two models coexist on the same infrastructure. Clastix Ready covers migration as a scoped engagement.

Sources

All claims on this page can be verified against primary documentation:

The claims addressed in “Claims about Kamaji you will find elsewhere” are taken from three articles published by vCluster Labs on its own blog. They are cited by title and date rather than linked, because none of them links to Kamaji’s documentation or source in turn:

  • “Kubernetes Tenant Isolation Models: Kamaji vs vCluster”, 27 June 2026
  • “Kamaji vs vCluster: Which Kubernetes Control Plane as a Service Actually Scales on Bare Metal GPU”, 15 July 2026
  • “Top Kamaji Alternatives for Teams Running Tenant Clusters at Scale”

The Clastix commercial offerings referenced above:

Community discussion of the management cluster failure scenario, and why a hosted control plane keeps tenant cluster operations running:

Last reviewed: 11 September 2026.