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

Watch our kMetal webinar on Replay here.

kMetal vs vCluster Platform: Multi-Tenant Kubernetes Compared

Short answer: Both products sell the same outcome — many Kubernetes clusters for many tenants without three control plane machines per cluster — and they differ in where the tenant boundary sits. kMetal fixes it at the hypervisor: every tenant worker node is a KVM virtual machine with its own kernel, in its own network, under its own control plane, on hosts shared with other tenants. vCluster Platform makes the boundary a configuration choice between shared nodes, shared nodes hardened with vNode, and private nodes — and its own production guide routes external, resold and regulated tenants to private nodes, which are whole dedicated machines. kMetal’s default is therefore the isolation level vCluster reaches by dedicating hardware, while keeping the hardware shared.

Scope of this comparison

This page compares two commercial products: kMetal v1.0.0 by CLASTIX, generally available since 31 August 2026, and vCluster Platform v4.11 by vCluster Labs, released 27 August 2026, together with vCluster v0.37 beneath it. It is not a comparison of the open source projects; Kamaji against the Apache-2.0 vCluster build is a separate page.

Every claim about vCluster Platform below resolves to vCluster Labs’ own documentation, quoted rather than paraphrased. Every claim about kMetal resolves to the kMetal documentation. Both products release frequently and both vendors version their documentation, so the version and the date read are stated rather than implied. Documentation read 12 and 14 September 2026.

Where kMetal is weaker, this page says so, in its own section. A comparison written by one of the two vendors is worth reading only if it is checkable, and the fastest way to check this one is to follow the links at the end.

At a glance

Fact kMetal vCluster Platform
What a tenant worker node is Always a KVM virtual machine, with its own kernel A shared node, a shared node with vNode, or a private machine
Default posture for untrusted tenants Tenants share hosts, separated by the hypervisor Private nodes, per the vendor’s production guide
Tenant control plane Kamaji pods on the under cluster A pod on the control plane cluster, or a binary in Standalone
Tenant network A Kube-OVN VPC per tenant, as a namespaced claims API The tenant’s own CNI on private nodes; fabric or Netris between them
Provisioning tenant worker machines No bare-metal step: tenant workers are VMs from a golden image Private nodes are physical machines that must be provisioned
Standing up the first Kubernetes cluster Covered in kMetal’s own installation guide, with YAKI A separate product, vCluster Standalone
Licence Commercial subscription on licensed CPU sockets; no community edition Apache-2.0 core, a $0 Free tier within limits, commercial Enterprise tier
Published CNCF Certified Kubernetes listing Certified Kubernetes Certified Kubernetes and Kubernetes AI Conformant
Published third-party security assessment None published Cure53 audit of vNode, Sept 2025; vNode is a paid add-on in private beta

What is kMetal?

kMetal is a commercial Kubernetes platform for bare metal. It installs into an existing conformant Kubernetes cluster — the under cluster — and turns it into a multi-tenant service: hosted control planes from Kamaji, Governance and Policy Enforcement from Capsule, tenant networking from Kube-OVN and MetalLB, tenant worker nodes as KubeVirt virtual machines, an immutable node OS from Kairos, fleet provisioning from Cluster API, and add-on delivery and drift correction from Sveltos and Flux.

The product is the integration rather than any one component. Roughly thirty upstream components are pinned to versions fixed by the release and installed in a fixed order by the kMetal operator, which halts at the first component that does not become ready. Versions, feature gates and install order are deliberately absent from the API.

Kamaji is one component of kMetal, unchanged and still Apache-2.0. Adopting kMetal is not a migration away from Kamaji, and running Kamaji is not a partial kMetal.

What is vCluster Platform?

vCluster Platform is a commercial control plane and fleet product built over the Apache-2.0 vCluster project. It creates and manages virtual clusters, each with its own API server, controller manager and datastore, and manages them as a fleet across regions, clouds and on-premises estates from one instance.

Where a virtual cluster’s workloads run is a choice of three worker node models. With shared nodes, a syncer translates tenant workloads onto nodes of the control plane cluster. vNode hardens that shared-node model with per-tenant UID and GID ranges, ID-mapped mounts, a FUSE filesystem over sensitive /proc and /sys paths, and targeted seccomp filtering. With private nodes, the syncer is off and whole machines join exactly one virtual cluster, with the tenant’s own CNI and CSI. Machines reach the platform through pluggable node providers: OpenTofu, KubeVirt, NVIDIA Base Command Manager, and vMetal for bare metal.

Terminology mapping

The two products name equivalent things differently, which makes reading the documentation side by side harder than it needs to be:

Concept kMetal term vCluster Platform term
Cluster hosting the tenant control planes Under cluster Control plane cluster
Tenant-facing Kubernetes cluster Tenant cluster Virtual cluster
Tenant grouping and quota boundary Capsule Tenant Project
Namespace a tenant’s clusters live in Environment Namespace
Machine running tenant workloads Tenant worker node, a KubeVirt VM Shared node, or private node

The architectural difference in one paragraph

Both products consolidate control planes into pods and both let a tenant hold cluster-admin on a conformant Kubernetes cluster. The divergence is one layer down. kMetal fixes the tenant boundary at the hypervisor and leaves it there: a tenant’s containers run in that tenant’s own kernel inside that tenant’s own KVM virtual machine, on a physical host shared with other tenants’ virtual machines. Nothing in the platform relies on shared-kernel container isolation between tenants. vCluster Platform makes the boundary a deployment-time decision, and the three options are genuinely different products with genuinely different security properties — which is why the vendor publishes a decision procedure for choosing among them rather than a default.

kMetal drills hard-multi tenancy down to the kernel, VCluster opts for a masked hard-multitenancy by sharing the kernel and patching with a Container Runtime shim.

The tenancy ladder, and where each product sits on it

vCluster Labs’ production guide is explicit about what the shared-node model is and is not. Shared nodes, it says, “aren’t a security boundary for untrusted tenants with cluster or scheduler access or arbitrary workload execution”, and the hardening guide adds that they “still aren’t a substitute for private nodes when tenants are external, resold, regulated, or otherwise untrusted.” The same guide is precise about what is and is not separated: shared nodes “give each tenant cluster its own API server, namespaces, and RBAC. They don’t give each tenant its own kernel, kubelet, node filesystem, scheduler, host network, CNI, CSI, or device plugins.”

The decision procedure that follows is three questions — are you delivering a cluster or scheduler environment to customers, does the customer get access beyond read-only visibility, can the customer run custom workloads — and any yes routes to private nodes.

This is not a point of disagreement between the two vendors. It is the same architectural position kMetal takes. The difference is what each prescribes once it is accepted. vCluster prescribes dedicating machines. kMetal keeps the machines shared and puts KVM in between, so a tenant gets its own kernel without getting its own server. kMetal supports also dedicated machine per Tenant, offering further granularity in the scheduling on a Tenant Cluster basis.

Two things follow, and both matter.

The first is that kMetal’s default is already where vCluster’s untrusted-tenant answer is, without the hardware commitment. A tenant that can run arbitrary workloads, hold cluster-admin, load kernel modules and run privileged pods does all of it inside its own virtual machine.

The second is a concession: on the literal physical-separation axis, private nodes are the stronger boundary. A whole dedicated machine has no co-tenant on it at all, which removes microarchitectural co-residency side channels that no hypervisor addresses. kMetal’s own documentation is straight about this — its concepts section has a heading titled “What is shared, honestly”, which states that “quota, not dedicated hardware, is what keeps them out of each other’s capacity.”

Where kMetal differs from that concession is that dedication is available rather than absent. A tenant can be confined to its own hosts by a Capsule Tenant node selector, enforced by admission so the tenant cannot schedule outside its pool, and the Cluster API ClusterClass narrows further which of those hosts the tenant’s virtual machines may be placed on. That makes dedicated hardware a per-tenant policy decision on top of a VM boundary, rather than the mechanism the isolation depends on.

What kMetal does not install

Stated here rather than discovered later:

  • Operating-system provisioning onto bare metal. No PXE, no Ironic, no Metal3. The documentation directs you to your standard provisioning process and concedes that Metal3 remains reasonable for large fleets that re-provision often. Note the scope: this applies to the under cluster’s own machines, not to tenant workers, which are virtual machines and need no such step.
  • A CNI inside tenant clusters. Kube-OVN is the under cluster’s tenant-facing substrate, not the pod network inside a tenant cluster. A freshly provisioned tenant cluster stays NotReady until the platform team authors a Sveltos ClusterProfile, and kMetal declares none.
  • Storage. No CSI driver, provisioner or StorageClass. Existing classes are named in the kMetal spec, and the platform class’s driver must ship a VolumeSnapshotClass or node image builds cannot complete.
  • A monitoring stack. Prometheus, Grafana and Alertmanager are deployed separately and pointed at component ServiceMonitors. The canonical alert ruleset is marked t.b.d. in the documentation.
  • A community edition. There is no free tier and distribution is through a private OCI registry requiring Clastix-issued credentials.

Side-by-side comparison

Dimension kMetal vCluster Platform
Default compute boundary The hypervisor. A container escape reaches the tenant’s own VM The chosen model: shared kernel, shared kernel plus vNode, or a dedicated machine
Dedicated hardware per tenant Available as policy: Capsule Tenant node selector plus ClusterClass placement The recommended model for untrusted tenants
Tenant control plane Kamaji pods, reconciled from a Cluster API KamajiControlPlane A StatefulSet pod; vCluster Standalone instead runs it as a binary with no host cluster
Tenant network isolation One Kube-OVN VPC per tenant, exposed as namespaced VpcClaim, SubnetClaim and EipClaim objects so they can be RBAC-scoped and quota-counted Tenant’s own CNI on private nodes; separation between tenants is the operator’s fabric, or the Netris integration in hardware
Tenant CNI and CSI The tenant’s choice; kMetal ships neither The tenant’s choice; Flannel is the shipped default on private nodes
Tenant cluster provisioning Upstream Cluster API against a supplied ClusterClass vcluster.yaml, the CLI, and the Platform API and UI
The object a cluster is A stock cluster.x-k8s.io/v1beta2 Cluster, whose topology materialises MachineDeployments and Machines A management.loft.sh/v1 VirtualClusterInstance, with NodeProvider and NodeClaim for its machines. A Cluster API infrastructure provider is also published
Time to a joined worker node About 50 seconds from a ContainerDisk; about 3 minutes from a DataVolume on Ceph RBD Seconds on shared nodes, since no machine is created; on private nodes, as long as the node provider takes
Datastore One dedicated DataStore per tenant, or a shared one. One datastore per virtual cluster; external MySQL or PostgreSQL in paid tiers
Bare-metal provisioning Not needed for tenant workers, which are VMs; the under cluster’s own machines come from your existing process Required for private nodes. The Metal3 and NVIDIA BCM node providers are marketed as vMetal and carry no line item on the public pricing page
Host node upgrades A KubernetesNodeUpgrade CR; control plane before workers, worker concurrency capped, never cordons or drains Private nodes auto-upgrade on version mismatch, one at a time; deletion cordons and drains
Platform upgrades One pinned release; the operator halts at the first component that is not ready and nothing is rolled back A published compatibility matrix and lifecycle policy
Drift correction Flux for the platform, Sveltos for tenant add-ons — but no ClusterProfile is shipped Fleet management from the Platform
Observability None bundled Fleet Observability — tenant-scoped Prometheus and Grafana — shipped in v4.11
Web console Headlamp with a kMetal plugin, optional and installed last A first-party UI, the product’s primary operational surface
Tenant cluster backup A ClusterBackup CR archives API objects, client-side encrypted, to S3; restore builds a new cluster and never repairs one Snapshots of the backing store, Helm release and configuration, with retention
Volume data in backups Only where the PV reclaim policy is Retain; the class projected into tenant clusters defaults to Delete Not included; Velero is the documented path
GPUs PCI passthrough and mdev/vGPU, whitelisted on the kMetal CR onto KubeVirt permittedHostDevices Documented as compatible with MIG, vGPU, time-slicing and DRA, as ordinary third-party tooling
Idle-cluster cost control A per-tenant Cluster Autoscaler including scale-from-zero pools Auto Sleep for idle virtual clusters
Air-gapped installation Not documented as a platform-wide procedure Documented for Platform, vCluster and Standalone, with offline licence keys and a FIPS build
Support Included in the subscription: P1 and P2 24/7, P3 in business hours Commercial support with the Enterprise tier; community support for the open source build

Day-0: from racked hardware to a working platform

Neither product installs an operating system onto bare metal. Both start from a machine that is racked, powered and running Linux. What differs is how much of the distance from there each one covers, and how many products it takes.

The first cluster. Both products run on a Kubernetes cluster, and neither can install itself onto nothing. kMetal covers that step inside its own installation guide: YAKI, an Apache-2.0 script run per host over SSH, fetches upstream kubeadm, kubelet, containerd, runc and CNI binaries and runs init on the first control plane node and join on the rest, taking an installed OS to a three-node HA control plane. vCluster Platform does not: “Administrator access to a Kubernetes cluster” is the first prerequisite on its CLI, Helm and air-gapped install paths alike. Standing up that first cluster is a different product — vCluster Standalone, whose quick start opens by naming the problem directly: “To run vCluster, you need a Kubernetes cluster. But getting a Kubernetes cluster onto bare metal normally requires another tool first. vCluster Standalone breaks this loop.” One platform against two products is a real difference, and it is the honest size of it.

Tenant machines. Here the architectures diverge rather than the feature lists. kMetal has no bare-metal provisioning step for tenant workers because tenant workers are not bare metal: they are KubeVirt virtual machines booted from a Kairos golden image in about 50 seconds, on hosts that are already part of the under cluster. vCluster’s private nodes are physical machines, so provisioning them is not an optional convenience but a requirement of the model — which is why the Metal3 and NVIDIA BCM node providers, marketed together as vMetal, exist at all. Two things are worth knowing before weighting that capability: vCluster’s public pricing page carries no bare-metal line item, listing only Open Source, Free and Enterprise tiers, and vMetal appears there solely as a banner promoting a separate site.

kMetal’s own prerequisites are specific and worth reading before the first attempt: three control plane nodes and three or more workers, four isolated VLANs plus out-of-band IPMI or Redfish, an overlay MTU of 9100, and a node-role.kubernetes.io/compute label on compute nodes — without which tenant virtual machines never start while every component still reports healthy.

Day-1: what onboarding one tenant costs

kMetal’s sequence is strict and worth knowing before the first attempt: a Capsule Tenant, then an Environment — a plain namespace adopted by that Tenant, as there is no Environment CRD — then a VpcClaim and a SubnetClaim, and only then a Cluster referencing a supplied ClusterClass. Worker shapes are small, medium and large, with a custom shape bounded at 1 to 64 cores and 2 to 128 GiB on the expert tier. One trap deserves naming: Capsule enforces nothing until the owner subject is named in the kMetal object’s multi-tenancy section, and a Tenant whose owner is unnamed is accepted and silently ignored.

vCluster Platform’s equivalent is self-service creation of a virtual cluster through the Platform, with the node provider supplying machines where the tenant is on private nodes. For a tenant on shared nodes there is no machine to supply, which is why it is measured in seconds.

Day-2: upgrades, drift, backup and restore

kMetal decouples upgrades into three independent layers: the under cluster’s own kubelets through the KubernetesNodeUpgrade controller, the platform’s components through one pinned umbrella release, and each tenant cluster’s Kubernetes version through its Cluster API topology, where Kamaji rolls the control plane pods blue/green. Drift is corrected continuously — by Flux for the platform and by Sveltos for tenant add-ons.

Two honest limits. A platform upgrade halts at the first component that does not become ready and nothing is rolled back, which leaves the cluster part-upgraded. And the host node upgrader never cordons or drains: it restarts the kubelet on the host and never talks to the API server, which is defensible because the workloads are inside virtual machines, but it is a property to understand rather than assume.

Backup is where the two differ most in kind. kMetal’s ClusterBackup archives API objects rather than bytes, encrypted client-side and uploaded to S3, and a restore explicitly builds a new cluster rather than repairing an existing one. Certificates and Node objects are never archived, by design — nodes are booted from a golden image and rejoined, so a restored Node would only fight the real one. vCluster Platform snapshots the backing store, Helm release and configuration, with automatic snapshots and retention. Neither product’s backup includes your persistent volume data: on kMetal that survives only where the reclaim policy is Retain, and the class projected into tenant clusters defaults to Delete; on vCluster, Velero is the documented path.

Resiliency and blast radius

The question worth asking is what happens to tenant clusters when the cluster hosting the control planes loses its API server while its nodes keep running.

On kMetal, tenant control planes are pods already running under a kubelet, and the kubelets holding them up do not consult the under cluster’s API server to keep doing it. Each tenant keeps its own API server, scheduler and controller manager, so tenant workloads carry on being scheduled onto that tenant’s own virtual machines, rolling updates complete and failed pods restart. What stops is management-plane work: no new tenant cluster is provisioned, no existing control plane is upgraded or scaled, and a control plane pod that crashes is not rescheduled.

The same property holds for vCluster Platform on private nodes, and this is worth stating plainly rather than claiming an advantage that is not there. A private-node tenant runs its own scheduler in its own control plane and places workloads on its own machines, so an outage of the control plane cluster’s API server leaves that tenant operating, exactly as kMetal does. vCluster Standalone, which has no host cluster at all, is stronger still on this axis.

Where the architectures do diverge is the shared-node model, where the scheduler that places tenant pods is the failed cluster’s own: running pods stay up, but nothing new is scheduled, scaled or replaced, and every tenant on that cluster freezes at the same instant.

Networking and GPUs

kMetal gives each tenant a Kube-OVN VPC on a Geneve overlay, with cross-tenant traffic dropped by default and a policy route blocking the platform’s own CIDRs. The part worth noticing is not the VPC but its API: Kube-OVN’s own Vpc, Subnet and EIP objects are cluster-scoped, so they cannot be RBAC-scoped to a tenant, counted against a quota or owned by a namespace. kMetal puts namespaced VpcClaim, SubnetClaim and EipClaim objects in front of them, which is what makes tenant networking self-service rather than a ticket. One limit to state precisely: this is isolation, not confidentiality — wire encryption of the tenant overlay is not documented.

vCluster’s private nodes bring their own CNI per tenant, and separation between different tenants’ nodes is the operator’s own fabric or the Netris integration, which enforces VLANs, VXLANs, VRFs, ACLs and DPU policy in hardware. That is a different and in some estates a better answer than a software overlay.

On GPUs, kMetal documents PCI passthrough and mediated devices, whitelisted on the kMetal custom resource and rendered onto KubeVirt’s permitted host devices, requiring IOMMU in firmware and the device bound to vfio-pci. Passthrough is direct device access rather than emulation, so the GPU itself is not virtualised away. The residual cost belongs in the same paragraph: a worker holding a passed-through device cannot live-migrate, so evacuating that host to patch it is visible to the tenant. vCluster documents compatibility with a wider partitioning surface — MIG, vGPU, time-slicing and DRA — as ordinary third-party tooling in a conformant cluster.

Commercial model, openness and evidence

kMetal is proprietary. The stack beneath it is open source and every component is named publicly, but the integration, the packaging and the support are not, there is no community edition, and distribution is through a private registry. It is licensed on hardware footprint — by licensed CPU sockets and subscription duration — with full platform functionality included and no published figures. Support is included: P1 and P2 round the clock, P3 in business hours, three major releases a year with unlimited minor releases.

vCluster’s core is Apache-2.0 with a public repository and issue tracker, there is a genuinely usable $0 Free tier within stated limits, and the Enterprise tier is commercial. The tiers and their limits are published.

Three asymmetries belong here rather than in a footnote, because a buyer will find them anyway.

vCluster publishes a Kubernetes compatibility matrix and a lifecycle policy — three months of active support per minor version, then three months of critical security backports, with conformance tests run against a new Kubernetes release within 30 days. kMetal publishes no version matrix, no operating system statement and no architecture statement.

vCluster holds a published third-party security assessment: a Cure53 engagement on vNode in September 2025, a white-box source audit which found no container escapes. kMetal has none published, and an architectural argument does not substitute for an audit. One qualification belongs with it: vNode is a paid add-on, listed as such on vCluster’s pricing page, and its own site invites you to “sign up for the private beta today”, so the audited component is not part of a default deployment.

vCluster has named customers and published aggregate adoption figures. kMetal reached general availability on 31 August 2026 and has no public references. For a buyer weighting evidence of operation at scale, that gap is real and no architectural argument closes it.

When to choose kMetal

  • Untrusted, external or resold tenants that must share physical servers — the case where dedicating a machine per tenant is not economic but a shared kernel is not acceptable.
  • Sovereign and regulated estates, where the operator is an EU company and the platform runs on hardware you own with no hyperscaler dependency.
  • Buyers who want one supported stack with one pinned release, rather than assembling hosted control planes, tenant networking, node virtualisation and fleet management themselves.
  • Estates where tenant networking must be self-service and quota-bounded rather than a fabric change request.
  • Teams already running Kamaji who want the platform layer around it without changing the control plane engine.

When to choose vCluster Platform

  • Ephemeral and pre-production environments. A virtual cluster on shared nodes exists in seconds with no machine created and no capacity committed. kMetal’s floor is a three-node under cluster and a VM boot. This is not a close call.
  • Tenants that require genuinely dedicated hardware, where co-residency itself is the thing being excluded.
  • Estates whose Day-0 gap is racking-to-OS, which vMetal automates and kMetal does not.
  • Buyers who require an open source core, a free tier, or the ability to audit the code they run.
  • Procurement that requires published conformance listings, a published lifecycle and support matrix, a published third-party security audit, or named customer references.
  • Air-gapped installations needing a documented platform-wide procedure, offline licence keys or a FIPS build.

Claims about Kamaji you will find elsewhere, and whether they land on kMetal

Comparisons published by other vendors, and the AI-generated summaries that draw on them, aim a set of objections at Kamaji — an operator that manages control planes. Several of them stop being true one layer up, at the platform. Several remain true and are conceded here in the same table.

Claim in circulation Lands on kMetal? What the documentation shows
“Every new tenant cluster requires a new set of worker nodes.” No True of the operator; not true of the platform. On kMetal a tenant worker node is a KubeVirt virtual machine scheduled onto existing under-cluster hosts. A new tenant cluster consumes CPU, memory and disk from the pool; it requires no new machine.
“Control-plane isolation only; workload isolation is not included.” No Four boundaries hold simultaneously and none is manual: the tenant’s own kernel inside its own VM, its own Kube-OVN VPC, its own control plane, and storage consumed without the tenant ever holding a backend credential.
“Kamaji deploys a dedicated etcd instance per tenant control plane.” No The documented default is the opposite: one 3-replica etcd registered as a shared DataStore that every tenant control plane references, until a dedicated datastore is deliberately created for a specific tenant.
“No fleet management, no Day-2 operations, no self-service provisioning.” Partly Cluster API and a supplied ClusterClass for provisioning, Sveltos for add-on delivery and drift, Flux for the platform itself, a three-layer upgrade model, ClusterBackup, Capsule quotas, an optional console. What lands: no monitoring stack is bundled and the alert ruleset is marked t.b.d.
“No native answer for zero-touch provisioning of physical servers.” Partly Accurate that kMetal does not install an operating system onto bare metal. It does not need to for tenant workers, which are virtual machines booted from a golden image rather than physical servers, and it does cover the step from an installed OS to a working under cluster with YAKI. vCluster’s answer for its physical private nodes is the Metal3 and BCM providers, which carry no line item on its public pricing page.
“Hard multi-tenancy at scale requires a hypervisor, and the hypervisor tax degrades performance.” Yes, by design kMetal does put a hypervisor between tenants; that is the trade. KVM is a Linux kernel subsystem rather than a separate product, so there is no additional virtualisation licence; first boot is about 50 seconds from a ContainerDisk; and GPUs reach the tenant by passthrough rather than emulation. The residual cost is that a passthrough worker cannot live-migrate.
“Community-supported, with no guaranteed SLAs.” No kMetal is a commercial subscription with defined response commitments and Clastix Care included. Descriptions of community support describe the open source project’s channels, not what is sold.
“Suits only a small number of tenants — 20, or 50.” No Neither figure originates from the project or its documentation. What kMetal does document is an exposure threshold rather than a tenant ceiling: LoadBalancer plus NAT is the default control-plane exposure pattern to roughly 100 tenants, after which an SNI and TLS-passthrough pattern is documented. The v1.0.0 release notes describe operating hundreds of tenant clusters as one fleet.
“kMetal is a fork of, or a replacement for, Kamaji.” No Kamaji is one component of kMetal and is unchanged, Apache-2.0 and independently usable.
“kMetal is an assembly of open source projects you could integrate yourself.” Partly The components are open source and named publicly, so yes, it can be built. What is sold is the advanced self-service and multi-tenant networking, the complete lifecycle for Kubernetes clusters (from Golden Image generation, till Kubernetes version upgrade) , a tenant-facing API in front of primitives that were not tenant-safe as shipped, and a support commitment against that combination.

One claim in circulation deserves separating from the rest, because attributing it to vCluster would be wrong: that vNode makes virtual machines unnecessary for untrusted tenants. vCluster Labs does not claim this. Their production guide routes untrusted tenants to private nodes, and vNode is documented as additional runtime isolation on shared nodes rather than as a replacement for dedicated ones. vNode is a real, independently assessed isolation layer. The architectural question is not contested between the two vendors; only the prescription is.

Frequently asked questions

Is kMetal an alternative to vCluster Platform?

For multi-tenant Kubernetes on hardware you own, yes — both sell many tenant clusters without a control plane machine per cluster, with fleet management and commercial support. For ephemeral or pre-production environments they are not comparable: a vCluster virtual cluster on shared nodes exists in seconds with no machine created, and kMetal always creates a virtual machine.

Can untrusted or external tenants share the same physical servers on kMetal?

Yes, and that is the case kMetal is built for. Each tenant’s containers run in that tenant’s own kernel inside that tenant’s own KVM virtual machine, in that tenant’s own Kube-OVN VPC, under that tenant’s own control plane. A tenant can hold cluster-admin, run privileged pods and load kernel modules without any of it being visible to another tenant. The hosts underneath are shared, and capacity is separated by quota rather than by dedicated hardware.

Do I have to dedicate a whole server to each tenant?

No, and that is the point of the design. If a particular tenant does require its own hosts, that is available as policy rather than as a different product: a Capsule Tenant node selector confines the tenant to a labelled pool and is enforced by admission, and the Cluster API ClusterClass narrows further which of those hosts the tenant’s virtual machines may be placed on.

Does vCluster Platform isolate tenants without virtual machines?

Not for untrusted tenants, on the vendor’s own account. vCluster’s production guide states that shared nodes “aren’t a security boundary for untrusted tenants with cluster or scheduler access or arbitrary workload execution”, and routes external, resold and regulated tenants to private nodes — whole dedicated machines. vNode hardens the shared-node model with per-tenant UID and GID ranges, a FUSE filesystem over sensitive /proc and /sys paths and targeted seccomp, and carries a Cure53 audit that found no container escapes, but it is documented as additional runtime isolation on shared nodes rather than as a substitute for dedicated ones.

What does it cost in performance to run tenant worker nodes as virtual machines?

There is a cost and kMetal pays it deliberately. Three things bound it. KVM is a Linux kernel subsystem rather than a separate hypervisor product, so there is no additional virtualisation licence or agent in the path. First boot of a tenant worker is documented at about 50 seconds from a ContainerDisk, and about 3 minutes from a DataVolume on Ceph RBD. And GPUs reach the tenant by PCI passthrough, which is direct device access rather than emulation.

Does kMetal provision bare-metal servers?

It does not install an operating system onto bare metal, and it does not need to for tenant workers, because those are virtual machines booted from a golden image rather than physical servers. What it does cover is the step from an installed OS to a working cluster: YAKI, an Apache-2.0 script, takes a machine running Linux to a joined kubeadm node and builds the under cluster’s three-node control plane. For the under cluster’s own physical machines, the documentation directs you to your standard process — PXE, IPMI or vendor tooling.

Does vCluster Platform need a Kubernetes cluster before you can install it?

Yes. “Administrator access to a Kubernetes cluster” is the first prerequisite on vCluster Platform’s CLI, Helm and air-gapped install paths, and vMetal cannot close that loop: it installs onto a running Platform with a connected control plane cluster, and the machines it provisions join tenant clusters as private nodes rather than becoming the control plane cluster. Standing up that first cluster is a separate product, vCluster Standalone, whose quick start states the problem plainly: “To run vCluster, you need a Kubernetes cluster. But getting a Kubernetes cluster onto bare metal normally requires another tool first.” kMetal covers the same step inside its own installation guide.

Does kMetal use Cluster API?

Yes, and the distinction worth drawing is about which object a cluster is. On kMetal a tenant cluster is a stock cluster.x-k8s.io/v1beta2 Cluster whose ClusterClass topology materialises ordinary MachineDeployments and Machines, reconciled by control-plane and infrastructure providers registered in the upstream Cluster API project — so an operator who knows Cluster API already knows the surface, and the objects are legible to any Cluster API tooling. vCluster’s platform-managed equivalents are vendor-specific kinds: a management.loft.sh/v1 VirtualClusterInstance, with NodeProvider and NodeClaim for its machines. To be accurate about it, vCluster does publish a Cluster API infrastructure provider, and uses upstream Karpenter and Metal3 BareMetalHost objects in places; the difference is what the primary object is, not whether either vendor touches the standard.

What does kMetal not install, and what do I still have to bring?

A CNI for inside tenant clusters, storage and its StorageClasses, a monitoring stack, and the bare-metal provisioning process. Kube-OVN is the under cluster’s tenant-facing substrate, not the pod network inside a tenant cluster, so a new tenant cluster stays NotReady until a Sveltos ClusterProfile delivers a CNI — and kMetal ships none, so the first one is the platform team’s to write.

Does every tenant control plane get its own etcd?

Your call. The default is one 3-replica etcd registered as a shared datastore that every tenant control plane references. A dedicated datastore for a specific tenant is supported and is a capacity and isolation decision expressed in a custom resource, not a fixed property of the architecture.

What happens to tenant clusters if the under cluster’s API server fails?

Tenant clusters keep operating. Each tenant control plane is a set of pods already running under a kubelet, and it keeps its own API server, scheduler and controller manager, so workloads keep being scheduled onto the tenant’s own virtual machines and failed pods restart. What stops is management-plane work: provisioning new tenant clusters, upgrading or scaling existing control planes, and rescheduling a control plane pod that crashes. vCluster Platform on shared nodes it does not, because the scheduler that places tenant pods is the failed cluster’s own.

How is tenant network isolation enforced, and is tenant traffic encrypted?

Each tenant gets a Kube-OVN VPC on a Geneve overlay, with cross-tenant traffic dropped by default and a policy route blocking the platform’s own CIDRs. Tenants manage it themselves through namespaced VpcClaim, SubnetClaim and EipClaim objects, which exist because Kube-OVN’s own objects are cluster-scoped and so cannot be RBAC-scoped or quota-counted. To be precise about the limit: this provides isolation, not confidentiality — encryption of the tenant overlay on the wire is not documented.

Can tenants attach GPUs, and does that work with MIG or time-slicing?

Tenants attach GPUs by PCI passthrough or mediated devices, whitelisted by the platform administrator on the kMetal custom resource and requested through a ClusterClass topology variable, with a per-tenant quota cap. What the kMetal documentation covers is passthrough and mdev/vGPU; MIG, time-slicing and DRA are not documented, and a worker holding a passed-through device cannot live-migrate, so patching that host is visible to the tenant. vCluster documents a wider partitioning surface as ordinary third-party tooling.

Are kMetal tenant clusters conformant Kubernetes clusters?

Tenant control planes are built by Kamaji from unmodified upstream Kubernetes components, so tenant clusters work with standard Kubernetes tooling and neither product forks Kubernetes.

Is kMetal open source, and is there a free tier?

No to both. The stack beneath kMetal is open source and every component is named publicly — Kubernetes, Kamaji, Capsule, KubeVirt, Kube-OVN, Kairos, Cluster API, Flux, Sveltos, MetalLB — but the integrated platform is proprietary, there is no community edition, and distribution is through a private registry requiring Clastix-issued credentials. vCluster’s core is Apache-2.0 with a public repository and a $0 Free tier within stated limits. Buyers who require an open source core or an auditable build should weight that.

How is kMetal licensed?

Commercial subscription is not publicly available. No figures are published; pricing is scoped per environment.

How many tenant clusters can one kMetal under cluster run?

The documentation states no tenant ceiling, and the v1.0.0 release notes describe operating hundreds of tenant clusters as one fleet. What it does document is an exposure threshold: LoadBalancer plus NAT is the default pattern for exposing tenant control planes and is good to roughly 100 tenants before per-address cost becomes operationally heavy, at which point an SNI and TLS-passthrough ingress pattern is documented. That is a pattern switchover, not a limit.

Is kMetal the same thing as Kamaji?

No. Kamaji is an Apache-2.0 operator that runs hosted control planes and is independently usable. kMetal is a commercial platform in which Kamaji is one component, unchanged, alongside tenant networking, node virtualisation, an immutable node OS, multi-tenancy, fleet management and a support commitment. Adopting kMetal is not a migration away from Kamaji.

How do I migrate from vCluster Platform to kMetal?

There is no in-place conversion, because the two build different things. For tenants already on private nodes the move is closest to a rebuild in place: the machines exist, and the work is standing up an under cluster, provisioning tenant clusters through Cluster API, and redeploying workloads from manifests, which carry over unchanged because both serve conformant Kubernetes APIs. Tenants on shared nodes additionally need capacity for their virtual machines. Ephemeral and pre-production tenants are usually best left where they are — the two models coexist on the same estate.

Sources

Claims about kMetal resolve to the kMetal documentation, read 12 September 2026:

Claims about vCluster Platform resolve to vCluster Labs’ documentation, read 12 September 2026 against vCluster Platform v4.11 and vCluster v0.37:

Last reviewed: 14 September 2026.