FAQs

kMetal is a bare metal Kubernetes platform built by Clastix. It unifies bare metal, virtualization, networking, and the operating system under a single cloud-native control plane, and extends Kamaji with a full operational ecosystem for running multi-tenant Kubernetes at scale. It is aimed at enterprises, cloud providers, and AI factories that want a private cloud Kubernetes platform without a separate hypervisor stack underneath it.

Yes. kMetal v1.0.0 reached general availability on 31 August 2026, following a beta period. The product documentation and home page carry the v1.0 GA designation.

The “k” in kMetal stands for Kamaji. Clastix describes it as “Kamaji on Bare Metal”: taking the Kamaji idea, which is that you should not have to manage control planes, all the way down to the metal, where you should not have to manage a hypervisor either.

No. kMetal is a commercial product. Some of the components it is built on are open source, such as Kubernetes, Kamaji, KubeVirt, Kube-OVN, Kairos, Capsule, Cluster API, Flux, and Sveltos, but the integrated platform, its packaging, its lifecycle automation, its self-service multi-tenant network, and its support are commercial. There is no community edition of kMetal itself.

Three audiences are named explicitly. Enterprises building a private cloud on hardware they already own. Cloud providers and managed service providers selling Kubernetes as a service. AI factories running GPU fleets that need tenant-level isolation. Vertical fit is claimed for telecommunications, hosting and MSPs, financial services, GPU and AI operators, and public sector and defense.

Clastix is direct about this: kMetal is not for single-cluster or hobbyist deployments. Smaller teams and single-cluster users are better served by open-source Kubernetes tooling, and organizations still sticking to a traditional hypervisor, or evaluating for a small number of clusters, should start with Kamaji, which is free. The value of kMetal is a function of fleet size.

No, and this is deliberate. The KVM layer in kMetal exists to provide kernel-level isolation for Kubernetes tenant clusters, not to run arbitrary Windows or Linux servers. A general-purpose hypervisor carries different requirements and expecting Virtual Machines to treat as pet, rather than cattle. kMetal is not positioned as a like-for-like VMware replacement for non-Kubernetes workloads.

kMetal has two decoupled layers. The “under cluster” is a Kubernetes cluster running on bare metal that hosts the platform itself: its control plane nodes run every kMetal controller plus all tenant control planes as pods, and its worker nodes supply the CPU, memory, and disk for the virtual machines that act as tenant worker nodes. The tenant layer is where tenant clusters live.

Eight capabilities, each mapped to proven open-source components. Hosted control planes come from Kamaji. Multi-tenancy governance comes from Capsule. Multi-cluster management comes from Cluster API with Kamaji and KubeVirt providers plus a kMetal ClusterClass. Networking comes from Kube-OVN, MetalLB, and kMetal’s own networking layer. Node management comes from KubeVirt on KVM with CDI, Kairos, and the kMetal image builder. Data protection comes from kmetal-backup and the KubeVirt CSI driver operator. Fleet management comes from Sveltos and Flux. Under-cluster node lifecycle comes from the YAKI Operator. Supporting components include cert-manager and an optional web console based on Headlamp with a kMetal plugin.

No. Tenant worker nodes run as KubeVirt virtual machines on KVM, the hypervisor built into the Linux kernel, directly on bare metal. There is no nested virtualization and no separate hypervisor product to license.

Three things you bring yourself. The primary CNI, because Kube-OVN runs as a secondary CNI and never takes over pod networking, so pod networking must already work before the operator starts. Storage, because kMetal ships no CSI driver, provisioner, StorageClass, or VolumeSnapshotClass. Credentials, because registry credentials and backup destinations are Secrets you create yourself.

Deliberately not very. The kMetal spec carries only the values that have no sensible default, such as the overlay interface, provider networks, address pools, and StorageClass names, plus a small number of explicit escape hatches. Component versions, feature gates, and install order are intentionally absent from the API, because a site that changed them would no longer be running a tested release.

Isolation on three axes at the same time. Each tenant gets a Kube-OVN VPC with no route to any other tenant. Tenant worker nodes are separate virtual machines with separate kernels rather than shared kernels. Each tenant gets its own control plane with its own certificates, datastore, and identity.

Real ones. Each tenant cluster is upstream, CNCF-compliant Kubernetes with a dedicated control plane, a dedicated datastore, a dedicated kernel, a dedicated network domain, and full cluster-admin access for the tenant. Tenants can run different Kubernetes versions, different add-ons, and different policies. This is a different model from namespace-scoped virtual cluster products.

Yes. A single tenant can own several clusters, for example development, staging, production, and disaster recovery, under one identity and one network.

No, and Clastix is precise about this. Capsule provides governance, not workload isolation. Hard isolation comes from the dedicated infrastructure model: the per-tenant control plane, the KVM kernel boundary, and the OVN routing domain. Capsule groups resources and applies policies and quotas on top of that.

Networking is built on Kube-OVN. Each tenant gets a VPC, implemented as an OVN logical router with its own routing table and access control lists and no static path to any other tenant’s VPC, containing one or more subnets. Cross-tenant traffic is dropped by default, and a default routing policy also blocks tenant traffic toward the platform’s own external CIDR so that a tenant cannot pivot into the platform. Tenants can use overlapping CIDR ranges.

Through namespaced claims inside their own environment rather than cluster-scoped objects. A VpcClaim requests the VPC, SubnetClaim requests subnets, and EipClaim requests an external address. Claims express intent and the controller writes the isolation-critical routing itself. Claim specifications are immutable, and because claims are countable objects they can be capped by quota.

There is one networking mode. Tenant traffic is always encapsulated in Geneve tunnels between under-cluster nodes, and jumbo frames are expected on the transport interface. Per-tenant separation on the physical wire is available at the egress edge by giving a tenant its own provider network.

Yes, kMetal gives the ability to the Platform Administrator to declare multiple provider networks and assign them at the VpcClaim creation: Tenants can decide theirs, or get one assigned by default, and policy enforcement can be configured to prevent the usage of non-entitled networks.

Through a provider network, typically a dedicated VLAN, that carries egress and hosts external addresses. A distributed gateway runs an external router port on every node, so there is no single egress chokepoint. Tenants claim an address with an EipClaim and annotate a Service. Reserved addresses keep an IP stable across service recreation, and quota enforcement prevents address exhaustion. IPs can be assigned in explicit mode (by annotating the Service) or dynamically (picking from the pool). Claims can be limited on a Tenant Cluster basis.

No. kMetal is storage agnostic. It installs no CSI driver, provisioner, StorageClass, or VolumeSnapshotClass, and it manages no storage cluster. You bring your existing storage, whether local disks, SAN, Ceph, or a vendor CSI driver, and name the classes in the kMetal specification. NetApp, Pure Storage, Dell, HPE, and Ceph are named as validated examples.

Volume snapshots. The storage class backing the platform’s own volumes must be served by a driver that ships a VolumeSnapshotClass, because golden operating system images are snapshotted and a fresh root disk is cloned for each machine. This rules out most node-local provisioners. Read-write-many access is also required for the virtual machine workflows if Virtual Machine live migration is required.

Through the KubeVirt CSI driver, with a controller on the under cluster and a node component inside the tenant cluster. A persistent volume claim created inside a tenant cluster becomes a volume on under-cluster storage that is hot-plugged into that tenant’s worker VM. Backend storage credentials never reach the tenant cluster. Quota is enforced twice: it is held against the tenant on the under cluster, and an admission webhook inside the tenant cluster rejects an over-quota claim at apply time rather than leaving it pending.

Tenant worker nodes are KubeVirt virtual machines, so they can be given a real PCI device through passthrough or a mediated device such as a vGPU. Permitted devices are whitelisted in the kMetal resource and threaded through the ClusterClass. Node prerequisites are IOMMU enabled in firmware, the appropriate kernel parameter set, and the device bound to vfio-pci. Consumption is capped per tenant with a resource quota targeting the device resource name. GPUs are pinned per tenant cluster rather than per namespace.

No. kMetal supplies the isolated, GPU-capable cluster and the passthrough plumbing. Framework and training orchestration choices such as Kubeflow, Ray, or similar remain with the tenant.

As Cluster API Cluster objects against a kMetal ClusterClass. Tenants choose a Kubernetes version and a machine size rather than assembling components, and customization happens through strictly typed ClusterClass variables. Control planes are upgraded blue/green, meaning the new version is stood up alongside the old one and then switched over. Worker nodes run an immutable Kairos-based operating system image that is updated by swapping the image rather than patching in place.

It is bootstrapped on bare metal with YAKI, the Clastix bootstrap and upgrade tooling, driven by the YAKI Operator. Node upgrades are expressed as a KubernetesNodeUpgrade resource handled by the YAKI Operator, which upgrades control plane nodes before workers, bounds concurrency, and waits for each node to return Ready at the target version. Terraform and Ansible are not required.

The kMetal Operator installes the correct sequence of components. Every component is expressed as a Flux object with versions, feature gates, and ordering pinned per release. Nothing is rolled back automatically on failure: a failed upgrade leaves the previous working version serving traffic.

A ClusterBackup is a namespaced object that sits next to the cluster it protects. The controller enumerates API objects, archives them, encrypts them client-side, and uploads them to S3 or S3-compatible storage. It captures objects rather than raw bytes, so a persistent volume only survives if its reclaim policy is set to Retain; volume snapshots cover the data itself. Restore is not a separate object: you create a new cluster and annotate it with the backup. The restored cluster receives its own certificate authority and identity, so it is a new cluster carrying the previous workloads rather than a resurrection of the old one.

Yes, an optional operator console based on Headlamp with a kMetal plugin. Nothing else in the platform depends on it and it can be left out entirely.

Cluster API and Terraform for provisioning and infrastructure as code. Flux and Helm for GitOps and packaging. Prometheus for metrics, with Grafana and existing alerting stacks integrated rather than replaced. Kube-OVN for software-defined networking and VPCs, MetalLB for API endpoint addresses, and Konnectivity tunneling for control plane to node communication. Any CSI-compliant storage driver. GPU passthrough via SR-IOV at the hardware level.

Yes. Tenant clusters are upstream CNCF-conformant Kubernetes, so your existing ecosystem tooling works unchanged. That includes ingress controllers, cert-manager, external-dns, service meshes such as Istio, Linkerd, or Cilium, container registries such as Harbor, CI/CD runners, backup tooling such as Velero with CSI volume snapshots, and standard operators. Argo CD runs inside tenant clusters in the normal way.

Yes. kMetal runs alongside an existing VMware estate during a transition, so workloads can be moved at your own pace. Note that kMetal is positioned as an alternative to platforms such as OpenShift, Rancher, Tanzu, Nutanix, and Mirantis rather than as an integration with them.

Clastix names Dinova and Tinext Cloud as early adopters taking a migration path away from Broadcom-era VMware licensing, citing a consolidation from 150 control plane machines to 3 at Dinova. Clastix is also recorded as an adopter of the Kairos project, where it describes kMetal as a multi-tenant Kubernetes platform designed for bare metal. Note that the larger names frequently associated with Clastix, including NVIDIA, OVHcloud, Rackspace, IONOS, Mistral AI, and Fastweb, are Kamaji or Capsule references rather than kMetal customers.

On a subscription basis, licensed by hardware footprint, with an annual commitment and renewal options, and full platform functionality included. Restrictions cover redistribution of platform components, reverse engineering or modification, and use beyond the licensed hardware.

Pricing is not published. It is scoped to your infrastructure and quoted by the Clastix sales team.

Clastix Care is included with every kMetal deployment. Coverage is 24 hours a day, 7 days a week for critical and major issues, and business hours for minor issues. It includes long-term support releases with security acceptance testing, monthly vulnerability reports in NIST NVD format, proactive CVE resolution with pre-disclosure notification, continuous fixes, per-customer feature prioritization, support for three major releases annually plus unlimited minor releases, a private Slack channel, and monthly office hours with Clastix engineers. Clastix Ready covers optional one-off services such as installation, architecture design, custom datastore work, training, production readiness reviews, and proof-of-concept delivery.

Yes, through the Explorer Program. You contact Clastix with your organization details and timeline and receive time-limited credentials for the Clastix OCI registry. The standard evaluation period is two weeks with one possible extension week assessed case by case. Evaluation support is best effort during business hours, evaluation use is for testing only, and production use requires a commercial license.

It is not publicly downloadable. Distribution is via Helm charts and container images in a Clastix OCI registry, with access provisioned after evaluation sign-up or license purchase.

The evaluation walkthrough, which is explicitly not a supported production deployment, calls for at least 4 CPU cores with 8 or more recommended, at least 8 GB of RAM with 16 or more recommended, at least 50 GB of disk with 100 or more recommended, two network interfaces because the second is required for the provider network, Ubuntu 24.04 LTS, and SSH with sudo. Real deployments and full proofs of concept require bare metal infrastructure.