kMetal 1.0 Features: Multi-Tenant Kubernetes on Bare Metal Without a Hypervisor Tax

Introduction: From the Control-Plane Tax to the Hypervisor Tax: Why We Built kMetal 1.0

Still running a separate hypervisor for Kubernetes? We need to talk.

In the past months, every conversation we had with prospects and customers was about how to simplify their Kubernetes stack. Hardware is scarce, budgets are small, and the hypervisor is now the most expensive thing on the bill. The VMware and Broadcom drama did not create the problem – it just amplified it and made it impossible to ignore.

A few years ago we coined the term "control-plane tax" when we launched Kamaji, because that was exactly what people were paying to run many Kubernetes clusters. The Hosted Control Plane architecture in Kamaji was our answer, and our customers fixed it. But talking to them, we kept hearing that the tax of inefficiency had not disappeared – it had just moved down a layer, into the hypervisor and into GPU allocation.

So with kMetal 1.0, now generally available, we are taking the same logic all the way down the stack. kMetal is the enterprise-grade platform for running Kubernetes at scale directly on the servers you already own – down to the bare metal, with no separate hypervisor layer to manage.

A single API covers the operating system, the bare-metal servers, GPUs and DPUs, Kubernetes control planes, cluster lifecycle, application delivery, and policies and quotas. Multi-tenancy, hosted control planes, a lightweight hypervisor, software-defined networking, self-service, and cloud native – one platform, one stack, one solution.
Here is what ships in kMetal 1.0, feature by feature: what it is, the problem it removes, and what that means for you.

These are kMetal 1.0 features and capabilities that we will dig deeper into in this article:

Control Plane Management

Hosted Control Planes

The CLASTIX approach to control plane management is that every tenant gets its own Kubernetes control plane, but they run as lightweight pods on a small shared set of management nodes – each with its own isolated cluster database instead of dedicated machines per tenant.

Giving each tenant a dedicated control plane the traditional way needs about three control-plane machines per tenant – for 50 tenants, that’s 150 machines that run no tenant workloads.

Run the control planes for 50 tenants on about 3 shared nodes instead of ~150 dedicated machines – far less hardware to buy, power, and manage. Each idle tenant control plane uses only ~200 mCPU / ~256 MiB, and sleep mode takes idle environments to zero.

Dedicated Tenant Clusters

Each tenant gets a real, standards-compliant Kubernetes cluster of their own – full administrative control, their own API, upgraded on their own schedule – not a shared slice of someone else's.

Sharing one cluster across tenants gives each tenant only a limited view and can never safely grant them full control.

The managed-cluster experience – a real private cluster per customer, independently versioned – on infrastructure you own and control.

Multiple Clusters per Tenant

A single tenant can own several Kubernetes clusters (for example dev, staging, prod, DR) under one identity and network.

Tenants usually need more than one cluster, but many platforms tie a tenant to a single cluster.

Give each customer a whole fleet of clusters under one identity – not the one-cluster-per-tenant limit of most platforms.

Turnkey Tenant Clusters

A complete tenant cluster – control plane, worker VMs, and isolated network – is created end to end in a single step.

Traditional provisioning is a multi-step, procurement-bound process – stand up machines, wire networks, bootstrap Kubernetes – often taking hours to days.

kMetal provides a full, ready-to-use cluster in about two minutes – clusters on demand instead of hours or days.

Under-Cluster Bootstrap

The platform's own management cluster is stood up on bare metal on a standard operating system with a lightweight, repeatable installer – the default for typical deployments.

Bringing up the platform's management cluster on bare metal otherwise means bespoke, non-repeatable manual setup.

A fast, repeatable way to stand up the platform itself – the same path already runs both live environments. Large fleets can use the automated bare-metal path.

Tenant Cluster Access

Each tenant reaches its own cluster from outside the platform through a dedicated, ready-to-use access point.

A tenant's cluster lives on an internal operator network that outside users cannot reach directly.

Tenants get a working connection to their own cluster without ever exposing your internal network.

Embedded Isolation

Embedded Compute Isolation

Each tenant's worker nodes run in their own virtual machines with a separate operating-system kernel – strong isolation built into the platform.

Container-only multi-tenancy shares a single host kernel, so one compromised or noisy tenant can affect the others on the same host.

Hardware-grade isolation between tenants – without buying or running a separate virtualization product.

Embedded Network Isolation

Each tenant gets its own private, isolated network, built into the platform and managed through the same Kubernetes interface as everything else.

Basic Kubernetes network rules share one underlying network; truly separating tenants otherwise means buying and running a separate networking product.

Every tenant is network-isolated out of the box – no VLAN wiring, external firewalls, or separate networking product to buy, staff, or run.

Self-Service Networking

Tenants and operators set up their own private networks on demand – networks, subnets, and public IPs – by simple declarative request, much like creating a VPC in the cloud.

Setting up per-tenant networks by hand requires privileged, platform-wide access and does not scale to self-service.

Tenants provision their own isolated networks in seconds – no ticket to the platform team and no privileged access handed out. Live on both environments today.

Multi-Subnet per VPC

A tenant network (VPC) is partitioned into multiple subnets – for example separate application and data-store segments within one tenant.

A single subnet per tenant forces environment or tier separation into separate tenants or clusters.

Separate segments (e.g. application vs data store) inside one tenant network for cleaner isolation – live today on multi-subnet tenants.

Isolated Per-Tenant Storage

Each tenant's storage is walled off from every other tenant's – its own storage class, capped usage, and the storage system's admin credentials never reach the tenant.

Because a tenant fully controls their own cluster, a storage driver placed inside it would leak the storage system's admin credentials and allow unbounded or cross-tenant access.

Per-tenant storage that is isolated by design – no shared credentials, enforced quotas, and no visibility into other tenants' data. (Isolation is by access and quota; the underlying pool may be shared.)

Tenant Workload Load Balancing

When a tenant's application asks for a public endpoint, the platform assigns an external IP automatically – the cloud load-balancer experience, on your own hardware.

Bare-metal clusters have no cloud load balancer, so exposing a tenant application externally normally needs manual per-service setup.

Cloud-style load balancing for tenant apps without a cloud – assigned automatically through the tenant's own cluster. (Shared-pool path is GA; dedicated per-tenant IP pools await an upstream fix.)

Reserved / Elastic Tenant IPs

Tenants reserve stable public IP addresses that stay the same even when their services are recreated – the cloud Elastic IP model.

IPs allocated per service change when the service is recreated, breaking DNS and external integrations, and can be lost to another tenant.

Stable, tenant-owned public IPs that survive service changes – so DNS and external integrations do not break.

Highly Available Networking

The tenant networking layer runs redundantly – no single node failure can cut connectivity or block network changes.

A single networking node is a single point of failure: losing it halts network changes for every tenant and can drop external traffic.

Tenant connectivity stays up through a node failure – the foundation for a production uptime commitment. (An advanced multi-active gateway mode is a later optimization.)

Bring-Your-Own Storage

Tenant clusters get persistent storage from whatever enterprise storage you already run – local disks, SAN, Ceph, and more.

Bare-metal clusters have no built-in persistent storage, and prescribing a specific storage product means new procurement and lock-in.

Persistent storage from the storage you already own – no new storage product to buy and no lock-in.

Fleet Management

Secure GPU Fleet Management

Provisioning and pooled management of GPUs shared across tenant clusters.

GPUs are scarce and expensive, and sharing them securely and efficiently across tenants is hard.

Share expensive GPUs securely and efficiently across many tenants – higher utilization, less waste.

Cluster Fleet Management

Operate hundreds of tenant clusters as one fleet – automatically keeping each cluster to its approved configuration and required add-ons, and handling routine day-2 work like patching and certificate renewal.

Managing clusters one at a time – applying policy, patching, renewing certificates – stops scaling past a handful, and clusters drift out of compliance with no single source of truth.

Run hundreds of clusters like one – policies enforced, drift corrected, and routine maintenance handled automatically, without headcount growing per cluster. Profile-driven convergence reconciles 100 control planes in under 150 seconds.

Unified Management Stack

Kubernetes-native management means that compute, networking, control planes, and cluster operations are all defined as Kubernetes resources and managed through one interface and one workflow – no separate virtualization or networking consoles.

A traditional stack is operated through separate virtualization, networking, and Kubernetes tools, each needing its own skills.

One platform, one solution, one skill set instead of three consoles and three teams – lower training, hiring, and running cost.

Declarative Provisioning

Clusters are created and managed through the industry-standard Kubernetes provisioning API – the same open approach the wider ecosystem uses.

Custom, per-infrastructure provisioning scripts are slow to build, fragile, and drift out of step with upstream Kubernetes.

Deploy on any infrastructure using an open standard – no proprietary layer, no lock-in, and your team's existing Kubernetes skills apply.

Delivery & Lifecycle Management

The whole platform is defined as code and installed, upgraded, and kept in sync automatically from a single source of truth.

Assembling a bare-metal Kubernetes platform by hand is slow, error-prone, and drifts between environments.

Install and upgrade the entire platform reliably and repeatedly – fewer manual steps, fewer outages, faster rollouts. This model runs both live environments today.

Standardized Cluster Blueprints

Reusable blueprints define a standard cluster – operating system, Kubernetes version, storage, networking, policies, and required add-ons – applied consistently across the fleet.

Without enforced standards, every cluster becomes a one-off that drifts over time and grows unsupportable.

Every cluster is consistent, production-ready, and audit-friendly by default – no snowflakes to troubleshoot.

Self-Service Provisioning

Tenants create and manage their own clusters within limits you set – approved versions, quotas, network rules, and required components.

When every cluster request goes through a central team, that team becomes a bottleneck for the whole business.

Tenant self-service speed with full guardrails – the central team stops being the bottleneck while keeping control of policy.

Rolling Upgrades

Tenant control planes are upgraded by standing up the new version alongside the old and switching over, and Kubernetes versions roll out across the fleet through the normal workflow.

Cluster upgrades traditionally mean maintenance windows and downtime risk for every cluster.

Upgrade tenant clusters without downtime windows – control-plane swap in ~16s, zero downtime, and fleet-wide version rollout coordinated for you.

Operator Console

A web console for operators to view and manage clusters, networks, and tenants – including create and edit – not just the command line.

A command-line-only workflow limits who can operate the platform and keeps non-experts dependent on the platform team.

A graphical way to run the platform, so it is not command-line-only and non-experts are not stuck waiting on specialists.

Backup & Restore

Backup and restore of tenant control-plane state and persistent data.

Without a built-in backup path, recovering from data loss is manual, slow, and unreliable.

A reliable, tested way to recover tenant clusters and their data after loss.

Immutable Node OS

Worker nodes run a locked-down, versioned operating-system image, updated by swapping in a new image rather than patching in place.

Hand-patched, changeable node operating systems drift apart between nodes and are hard to reproduce or audit.

An identical, reproducible, auditable operating system across every node – no drift, and clean rollbacks.

The kMetal 1.0 Bottom Line: Less Hardware, Fewer Tools, Lower Cost

Every feature above answers the same question we have been hearing for years: how do we run more Kubernetes on less hardware, with fewer tools and fewer teams, without giving up isolation or control?

Hosted control planes turn ~150 control-plane machines for 50 tenants into 3. Kernel-level virtualization gives every tenant hardware-grade isolation without a separate hypervisor on the bill. Software-defined networking, elastic IPs, and cloud-style load balancing give tenants the public cloud experience on servers you already own. Blueprints, an immutable node OS, rolling upgrades, and fleet management keep hundreds of clusters consistent without headcount growing per cluster.

The result shows up on the bill: in internal analysis of on-premises deployments, kMetal cuts hardware depreciation by over 90%, SRE operations cost by over 65%, productivity overhead by over 60%, and energy and facility cost by over 50% – fewer servers to buy, power, and cool, run through one operational model instead of a fragmented toolchain.

And all of it is managed through one Kubernetes-native API and one operator console.

kMetal 1.0 is generally available today and already runs our live environments. It is also just one of the biggest pieces of news we are going to share – the best is yet to come.

If you are still running a dedicated hypervisor for Kubernetes, or evaluating a cost-saving initiative for your Kubernetes environment, let's talk.

Note: The figures used in the above article are illustrative, drawn from representative deployments; actual results typically vary by environment, workload and configuration.

Talk to us

Tell us about where you are and where you want to go. We want to know:

1. What you're working on

2. Your biggest challenge with it

Reach out to us here: contact form & email.