Introducing kMetal 1.0 – for Helping Enterprises Control & Scale Kubernetes More Efficiently

TL;DR

Run Kubernetes on bare metal with no separate hypervisor layer – with secure GPU fleet management built in for AI and GPU infrastructure at scale.

• What kMetal is – kMetal is for Kubernetes infrastructure only, nothing else.

• What kMetal does – It replaces the separate hypervisor layer for Kubernetes infrastructure; it does not integrate with other IaaS or cloud layers.

• Why infra teams need kMetal – Drop expensive/overkill hypervisors from your Kubernetes stack, or run Kubernetes on bare metal with a cloud-like experience – via the most efficient, cost-effective, lightweight, fully as-code platform available.

The Rising Cost of Running Kubernetes Infrastructure in 2026

We have just launched our enterprise-grade solution kMetal and here is why: Hardware scarcity is real. DRAM lead times are past 40 weeks, and NAND largely sold out for 2026, both of which hit control-plane and data-plane machines alike.* “You can't buy your way out” seems to cut both ways.

This is at least somewhat related to the ‘VMware/Broadcom exodus’ that we keep hearing about. Most enterprise OpenShift installs pair with VMware only to run Kubernetes worker-node VMs – a full, costly virtualization stack doing a job Kubernetes already orchestrates. VMware is fine for legacy VM estates where it shines, but for Kubernetes it is no longer sustainable, and Broadcom's 150–1000% price escalation has been a significant enough trigger to act.

Enterprises running Kubernetes on a full, costly virtualization layer – typically VMware, often under an equally costly OpenShift subscription – pay twice: once for orchestration Kubernetes already provides, and again in wasted resources and rising licensing cost, with Broadcom's price escalation as the trigger to move. kMetal is the cheaper alternative, as it drops that separate layer and runs Kubernetes directly on your existing hardware.

But cost isn't only about hardware and licensing, it's also about how the clusters themselves are run. Traditional Kubernetes is cumbersome to manage. The old model – one large cluster shared across multiple tenants – creates a single point of failure. Moving to multiple clusters improves security (a breach is contained to one cluster) but dramatically increases resource consumption and operational overhead. Our new solution lets organizations run as many clusters as needed without the resource drain – the right architecture for this problem.

Introducing kMetal 1.0: Bare-Metal Kubernetes With No Separate Hypervisor Layer

We kept hearing the same thing from the teams we work with: they were paying for a full virtualization stack just to run Kubernetes, then paying again when hardware got scarce. And the licensing bill is only half of it, as running a separate virtualization platform underneath Kubernetes means two independent stacks to operate, with different tools, different interfaces, and often different teams.

So we built kMetal to take that layer out. It runs production Kubernetes directly on the servers you already own, with no separate hypervisor layer beneath the cluster – one platform, one interface, one team… all managed through the same Kubernetes API. So you reuse the hardware you have instead of buying more, stop paying for orchestration that Kubernetes already handles, and stop running two stacks where one will do.

What is kMetal? An Enterprise-Grade Bare-Metal Kubernetes Platform

kMetal is a bare-metal Kubernetes platform for organizations running Kubernetes infrastructure at scale. It is built for a single purpose: standing up and operating production Kubernetes directly on physical servers, with no separate hypervisor layer beneath the cluster.

kMetal runs on the hardware you already own, with no restrictive vendor compatibility list forcing a refresh.

What does kMetal do? Replaces the Hypervisor Layer for Kubernetes

kMetal provides a thin embedded virtualization layer sized to what Kubernetes needs (without the cost of a full VMware setup); it replaces the separate hypervisor layer for Kubernetes infrastructure.

kMetal lets platform teams remove expensive, overkill hypervisors from the Kubernetes stack and run Kubernetes directly on bare metal with a cloud-like, self-service experience – on the most efficient, cost-effective, lightweight, fully as-code platform available. The platform is fully declarative and API-driven, operated as code through Kubernetes-native constructs such as custom resources and Cluster API – so cluster provisioning, networking, and tenancy are defined and version-controlled like any other infrastructure.

kMetal also pools scarce, expensive GPUs securely across tenant clusters, so that operators have high utilization instead of stranded, idle hardware – a core enabler for AI and GPU infrastructure at scale.

From Kamaji to kMetal: the Next Logical Move

When we built Kamaji, it was the smart first move for Kubernetes infrastructure – it retired the control plane tax. kMetal is the next logical move, as it takes that same logic down to the metal and retires the hypervisor tax, as well.

kMetal takes the same ‘everything as one cloud-native control plane’ philosophy down to the metal:

• bare-metal provisioning

• kernel-native KVM virtualization with no separate hypervisor layer

• software-defined per-tenant networking

• immutable OS images

• secure GPU pooling shared across tenant clusters

All of it declared and reconciled as Kubernetes objects.

Who is kMetal for? Enterprise Kubernetes Infrastructure Teams

kMetal is for Kubernetes infrastructure only – so infrastructure teams running this. It removes the need for a separate hypervisor beneath the cluster, with a thin embedded one, sized to Kubernetes' needs (it does not integrate with other IaaS or cloud layers).

It replaces the separate hypervisor layer for Kubernetes infrastructure with a thin, embedded one, and gives platform engineering teams a cloud-like, fully self-service, as-code experience directly on bare metal. These are the capabilities that matter most to operators running Kubernetes at scale with hard multi-tenancy, where many tenants share the same hardware but must stay strictly isolated, and where efficiency compounds across a large fleet.

That’s why kMetal is a strong fit for telcos and cloud/service providers, MSPs and hosting providers, financial services, AI and GPU infrastructure operators, and the public sector and defense – anywhere efficiency, isolation, data ownership, and freedom from lock-in are priorities. For AI and GPU operators specifically, that includes securely sharing scarce, expensive GPUs across many tenants at high utilization.

kMetal best serves enterprises with genuine multi-tenancy requirements that want to operate multiple clusters on bare metal.

Who is kMetal NOT for?

kMetal is built for enterprise-scale Kubernetes infrastructure, not single-cluster or hobbyist setups. Smaller teams and single-cluster users are generally better served by open-source Kubernetes tooling.

kMetal 1.0 Capabilities and Features

In an incredibly simplified nutshell, kMetal 1.0 features and capabilities include:

How Does kMetal Support Infrastructure Sovereignty?

Sovereignty is increasingly a buzzword, but the bar it implies is extremely high – true sovereignty means owning the services, the hardware, and the supply chain. In that strict sense, it's almost utopian (you'd need to own the copper wires). Infrastructure sovereignty means owning your stack, avoiding lock-in, and security and ownership of your data. The more useful framing is resilience: the underlying aim of sovereignty is reducing dependency and improving the ability to withstand disruption.

kMetal enables any organization to become more sovereign in a practical sense – the ability to run on your own datacenter and hardware. Importantly, we don't create vendor lock-in.

Rather than relying on a hyperscaler, organizations are better served owning their infrastructure and building the solutions they need on top of it. kMetal enables any organization to become its own Kubernetes (or Kubernetes-as-a-Service) provider, using its own servers to build a sovereign cloud platform on Kubernetes – with CLASTIX as the software-engineering partner behind it, rather than another layer of lock-in.

How Does kMetal Improve Kubernetes Security Posture (KSPM)?

Kubernetes Security Posture Management (KSPM) is the ongoing work of knowing how every cluster is configured, catching drift from a hardened baseline, and proving it to an auditor. That checklist scales badly against a sprawling fleet, as 100 clusters (as an example) would mean:

• 100 independently bootstrapped control planes

• 100 sets of TLS certificates and etcd datastores to secure

• 100 places for configuration to quietly diverge

kMetal helps toward KSPM in large part via Hosted Control Planes – an approach that we pioneered as an answer to the control plane management problem and also to minimize the ‘control planes tax’. By running every tenant control plane as pods in one hardened management cluster – with control-plane state and secrets consolidated centrally rather than scattered across every site – the surface a practitioner has to harden, monitor, and report on collapses from a fleet of moving targets to a single, professionally operated place.

kMetal is not specifically a ‘KSPM product’ – that is, it does not replace your scanning, policy, or CIS-benchmark tooling. What it does do well to aid your security posture comes down to how the control plane runs: because every tenant control plane runs as pods rather than on dedicated control-plane nodes, there are no control-plane nodes for a tenant to reach, so the management layer simply isn't exposed to them. That collapses the attack surface at the management layer close to nothing, and gives your scanning and policy tools far less to monitor and a far more uniform baseline to measure against – so a small platform team can hold a defensible posture across hundreds of clusters.

In short, fewer control planes means a stronger Kubernetes security posture, which makes it an ideal approach for security-sensitive and highly regulated environments where multi-tenant isolation, data ownership, and a centrally hardened control plane are non-negotiable.

How Is kMetal Different From Other Kubernetes Platforms?

kMetal competes in the Kubernetes management / container management platform category covered by industry analysts. It is scoped to Kubernetes infrastructure only and does not integrate with other IaaS or cloud layers, so it slots in underneath your clusters without trying to be a general-purpose cloud platform. Compute isolation, networking, and the node OS are all managed through the same Kubernetes API you already use, not a second console.

What sets kMetal apart from competitors within the Kubernetes/container management technology category is that it absorbs the infrastructure layer those platforms leave to a separate stack. The majority of competing Kubernetes platforms run on top of a hypervisor and a network product you procure, operate, and staff separately.

kMetal is the only platform that delivers hosted control planes, embedded VM-grade isolation on shared bare metal (compute and network), and fleet management in a single product. Competitors either require the isolation to be a separate layer, or – like vCluster – reach hard tenant isolation only by dedicating hardware per tenant or adding a separate sandbox runtime, giving up either the density or the single embedded model that kMetal keeps.

kMetal competitors seem to generally fall into three patterns:

kMetal is the single platform that delivers all three areas behind one Kubernetes API, to enable:

• No separate hypervisor layer for Kubernetes infrastructure, reducing licensing cost and operational overhead

• Cloud-like, self-service provisioning

• Consistent, as-code operations across the full cluster lifecycle, defined through Kubernetes-native APIs

• Purpose-built for multi-tenant Kubernetes, with tenant isolation as a core design goal
  

kMetal’s Real-World Validation

We developed the highly validated open-source software (OSS) Kamaji, which predates the industry's control-plane-as-a-service conversation. Our CEO & Co-Founder Adriano Pezzuto coined the phrase “control-plane tax” – now in use by the whole industry.

Forward-looking companies like Fastweb, IONOS, Mistral AI, NVIDIA, OVHcloud, and Rackspace… they all stopped paying the CONTROL PLANE TAX.

By brainstorming with our customers and community peers, however, we realized that everything BELOW the control plane was still running the same way, with separate:

• Hypervisor stack

• Networking

• Provisioning tooling

• On-call

So now with kMetal we have taken the one-control-plane logic of Kamaji all the way DOWN TO THE METAL. kMetal removes the separation with kernel-native KVM, software-defined networking, and immutable OS – all as Kubernetes objects, with one cloud-native control plane, from the metal up. The same Kamaji logic, now applied to your whole stack.

Dinova and TINEXT are great proof; they’re both taking a Broadcom-escape path with kMetal. Its 150→3 control-plane consolidation frees existing machines to redeploy as workers instead of buying new – reusing hardware rather than being forced to rebuy. That was a key reason we won Dinova as a customer.

What's Next for kMetal? Roadmap and Further AI Factory Enablement

We work closely with AI Factories and agentic workloads and will guide our customers through their needs in these areas (the way we did by pioneering the Hosted Control Plane for their control plane management troubles).

Continuing to scale our built-in AI Factory enablement – i.e. our bare-metal GPU efficiency (secure GPU sharing across tenants), cloud-style tenant isolation, self-service provisioning – is a key aspect of kMetal’s design philosophy. We are working on a plan to greatly scale these and other kMetal capabilities, to continue helping our customers run Kubernetes at scale with less hardware, lower operational overhead, and more predictable costs. Look for more news on this very soon.

Talk to us

Make history with us. Tell us about where you are and where you want to go. We would love to learn:

1. What you're working on

2. Your biggest challenge right now

You can also ask us for a Solution Brief or Whitepaper if you want to dig deeper on your own first. We are here to help. Here's how to reach us: contact form & email.

What Do Companies Say about CLASTIX?

Simone Morellato, Co-Founder & CMO of Project Sveltos:

“At Sveltos we are excited to see how this solution, in collaboration with Clastix.io, supports cloud providers like Dinova in delivering top-tier Managed Kubernetes Services. We encourage you to explore Sveltos and Kamaji to enhance your Kubernetes offerings.”

Emanuele Roserba, Head of Operations at TINEXT CLOUD:

“The better manageability of Clastix solutions and their independence from the underlying computing layer, in the end, made the decision easy.”

Luca Tagliavia, Head of ICT Multicloud BU at Fastweb:

“We are proud of the step forward we have taken with the new architecture, and we are very pleased to have partnered with the Clastix team for their deep expertise and unique approach to Kubernetes.” 

Jérémie Monsinjon, Head of Containers at OVHcloud:

“Kamaji works exactly as expected: it's simple, efficient, scalable, and I especially appreciate how Clastix has always been available for technical discussions and support."

Kevin Carter, Director at Rackspace:

“We are running the open-source project Kamaji within our Rackspace Spot platform today, and the results are impressive."

*Sources for DRAM lead times and NAND mostly selling out:

• https://ascglobal.com/dram-crisis

• https://storageswiss.com/2026/05/06/memory-and-flash-prices-not-coming-down

• https://a2globalelectronics.com/global-sourcing/the-2026-memory-chip-shortage-how-to-source-dram-and-nand-in-an-allocation-market

• https://www.kstmicro.com/kioxia-confirms-2026-nand-flash-production-capacity-fully-sold-out

• https://startupfortune.com/kioxia-sells-out-its-entire-2026-nand-flash-supply-just-as-ai-chips-ship