Bare Metal Kubernetes Guide: Run Certified K8s on GPUs Without a Hypervisor or kubeadm

Summary

• Bare metal Kubernetes eliminates the hypervisor and guest OS, so GPU workloads reach physical hardware directly without a translation layer.
• Two hidden taxes erode the advantage: reintroducing VMs for tenant isolation and treating kubeadm/k3s as permanent production platforms.
• The architecture that removes both taxes combines automated bare metal provisioning, a CNCF-certified single-binary control plane, Private Nodes for tenant isolation, and kernel-native workload sandboxing.
• The vCluster product stack (vMetal, vCluster Standalone, Private Nodes, and vNode) delivers this architecture in production, with 50+ GPU Clouds & Fortune 500s running on 100K+ GPUs.

Bare metal Kubernetes puts the control plane and worker node components directly on the operating system of a physical server. No hypervisor. No guest OS. The kubelet runs on the host, and GPU workloads reach the hardware without passing through a translation layer.

That directness is the reason AI and GPU cloud providers choose it. But the conventional path to bare metal Kubernetes carries two hidden taxes that cancel the advantage. This guide names them, explains what they cost, and shows the architecture that removes both.

What Is Bare Metal Kubernetes?

Bare metal Kubernetes is Kubernetes running directly on physical servers, with no hypervisor or virtual machine between the control plane and the hardware.

In a VM-based Kubernetes setup, every node is a virtual machine. The stack looks like this:

Workload -> Container Runtime -> Kubelet -> Guest OS (VM) -> Hypervisor -> Host OS -> Physical Server

On bare metal, the VM and hypervisor layers are gone:

Workload -> Container Runtime -> Kubelet -> Host OS -> Physical Server

That missing layer is the entire point. Containerized workloads, including GPU kernels, reach physical hardware without any intervening abstraction. Latency drops, overhead disappears, and the GPU delivers its full throughput to the workload rather than to a translation layer.

Why AI Clouds Run Kubernetes on Bare Metal

GPU clouds have specific, computable reasons to avoid virtualization; architectural preference is not one of them.

Raw GPU performance: the hypervisor tax directly eats into GPU utilization and tenant performance. For GPU-intensive AI workloads, any overhead in the memory or I/O path compounds across thousands of operations per second. A point of overhead on a single GPU becomes a material cost at rack scale.

No noisy neighbors: in a virtualized environment, CPU scheduling jitter and I/O contention from one VM affects adjacent VMs, even across tenants that appear independent. For AI inference, where tail latency determines whether an SLO is met, that non-determinism is unacceptable.

Data residency: enterprises with data sovereignty requirements need certainty about where data physically rests and who controls the hardware. A bare metal deployment provides that certainty without relying on hypervisor configurations that can be difficult to audit.

Margin per GPU-hour: selling raw GPU capacity alone is a race to the bottom. Managed services add margin, but only if the platform itself is efficient. VM licensing costs and hypervisor overhead consume margin before a single GPU-hour is sold. Bare metal removes that cost category entirely.

The First Hidden Tax: The Hypervisor

The reasoning behind the hypervisor tax is understandable. Containers share a kernel, and a kernel exploit in one container can affect others. Teams choosing bare metal for performance then reintroduce VMs for isolation comfort, and in doing so, pay back the performance gains they just claimed.

The real costs for AI workloads are measurable:

• GPU throughput degradation. The hypervisor introduces a translation layer for memory access and I/O. What appears to be a small percentage overhead multiplies across parallel GPU operations. Observed gaps between VM and bare metal GPU performance can be substantial on I/O-bound tasks, sometimes doubling throughput in memory- or network-bound benchmarks.
• Tail latency spikes. Hypervisor scheduling is non-deterministic. For inference workloads with tight latency SLOs, the jitter introduced at the hypervisor layer causes periodic tail latency violations that are difficult to debug and hard to eliminate without removing the layer itself.

The correct answer avoids both the performance loss and the isolation risk. The Linux kernel provides the isolation primitives directly:

• seccomp filters the system calls a process can make, limiting the attack surface from userspace.
• cgroups enforce hard limits on CPU, memory, and device access per workload.
• namespaces virtualize system resources — PIDs, mounts, network interfaces, user IDs — at the kernel level, without a hypervisor.

These mechanisms reduce the kernel attack surface while preserving bare metal GPU performance, with no VM and no hypervisor tax. For workloads that require full VM-grade kernel isolation, vNode can be combined with gVisor or Kata Containers.

The Second Hidden Tax: The Bootstrap Distro

kubeadm and k3s are installers. They solve the problem of getting a first node running. Running a production GPU cloud is a separate problem they leave untouched.

The "Cluster-1 problem" is what comes after the first cluster is up. kubeadm delivers a bare control plane with unwired components. Platform builders are left to assemble independently:

• A load balancer (MetalLB or equivalent)
• A CNI plugin (Calico, Cilium, or equivalent)
• A storage solution
• CoreDNS and internal DNS

Each component has its own configuration surface, failure modes, upgrade cadence, and documentation. The official kubeadm documentation is a collection covering HA topology, HA etcd, kubelet integration, dual-stack networking, and troubleshooting as separate concerns.

k3s bundles several of these components out of the box, which makes it easier to start — but a bundled stack still needs to be maintained on someone else's upgrade cadence, and it does not remove the deeper problem: you are still operating a distribution as well as your cluster.

The operational consequence is that the platform team spends engineering time maintaining a bespoke Kubernetes distribution rather than building the managed services their AI customers are paying for. Every hour spent on etcd backup procedures or CNI upgrade compatibility is an hour not spent on the revenue-generating layer of the stack.

The bootstrap distro forces platform teams to become Kubernetes experts just to serve a model.

The Path That Removes Both Taxes

The four-step architecture below eliminates the hypervisor tax and the bootstrap tax without trading away isolation or certifiability.

Step 1: Provision bare metal with vMetal

vMetal is a bare metal provisioning orchestrator. It handles the machine layer: zero-touch PXE boot, automated OS installation, secure machine registration, and full lifecycle management. It is built on Metal3 (a CNCF project) and OpenStack Ironic.

The result is a fleet of registered, OS-ready physical servers available for cluster assignment, with no manual SSH session required.

Step 2: Deploy CNCF-certified Kubernetes with vCluster Standalone

vCluster Standalone installs a complete, CNCF-certified Kubernetes control plane as a single binary directly on Linux. It does not require k3s, kubeadm, or an external Kubernetes cluster; the binary is self-contained.

CNCF conformance certification means every required Kubernetes API is present and behaves identically to the upstream open source version. Platform builders know that workloads, tooling, and extensions that target standard Kubernetes will work without modification.

This is the direct answer to the Cluster-1 problem. The control plane is a single deployable artifact with a defined, certified interface.

Step 3: Deliver hard tenant isolation with tenant clusters and Private Nodes

Each tenant receives a fully isolated control plane: a dedicated API server, etcd instance, scheduler, controllers, RBAC policy, and admission control. That control plane is completely opaque to the tenant: they cannot see control plane logs, access etcd, or observe the control plane cluster. From their perspective, they have an independent Kubernetes cluster.

For production workloads, the default is Private Nodes: dedicated physical worker nodes joined privately and exclusively into a single tenant's cluster. There is no cross-tenant scheduling and no shared kernel between tenants at the data plane. This provides hardware-level isolation approaching the guarantees of a dedicated physical cluster, without the provisioning overhead of one.

Shared nodes are a separate configuration, reserved for development, testing, and CI/CD environments with trusted teams. They are not a security boundary for untrusted tenants; production environments use Private Nodes for hardware-level isolation.

Each tenant cluster also gets its own CNI. vCluster supports SR-IOV with Multus, Calico, and KubeOVN simultaneously across tenants, with no shared CNI requirement in the Private Nodes model.

Step 4: Isolate workloads with kernel-native sandboxing via vNode

For use cases requiring process-level isolation, including AI agent runtimes, dynamic code execution, and workloads that require root access or arbitrary package installs, vNode provides a secure sandbox using seccomp, cgroups, and Linux user namespaces. There is no VM or hypervisor overhead, and direct GPU access is preserved with near-zero performance impact.

vNode isolates the workload process and works alongside MIG, time-slicing, or DRA for hardware-level GPU partitioning and sharing. These layers address different parts of the stack.

The full stack (vMetal for provisioning, vCluster Standalone for the control plane, Private Nodes for tenant isolation, vNode for workload sandboxing) runs on bare metal from rack to tenant without a hypervisor or a bootstrap distribution anywhere in the path.

Teams running this architecture include Lintasarta, which launched Indonesia's leading GPU cloud in 90 days with 170+ tenant clusters in production. The platform is featured at NVIDIA GTC 2026 and runs across 50+ GPU Clouds & Fortune 500s on 100K+ GPUs.

What to Look for in a Bare Metal Kubernetes Stack

Architects evaluating approaches should measure against the two taxes directly. The table below maps each common approach to its overhead profile, isolation strength, and bootstrap cost.

‍

‍

VMs on bare metal and single-cluster-with-namespaces are built for different problems: the first for general-purpose workloads where a hypervisor was already in place, the second for internal platform teams with a single trusted tenant. kubeadm and k3s work well for bootstrapping and learning, but they do not belong in the control plane layer of a tenant-isolated GPU cloud.

Of the approaches compared, the tenant clusters with Private Nodes model is the only option that delivers all three at once: zero GPU overhead, a low bootstrap burden, and strong isolation (dedicated hardware rather than a shared kernel boundary). vCluster runs bare metal Kubernetes as a CNCF-certified, single-binary control plane with Private Nodes as the production default.

The two hidden taxes, the hypervisor reintroduced for comfort and the bootstrap distro that becomes permanent infrastructure to maintain, are the primary reasons bare metal Kubernetes fails to deliver its expected performance and operational benefits. The path that removes both is grounded in automated provisioning at the machine layer, moves up to a CNCF-certified single-binary control plane, and delivers production isolation through dedicated hardware rather than VM boundaries.

Ready to remove the hidden taxes from your bare metal Kubernetes stack? Request a demo to see how vCluster gets your GPU cloud to production faster.

Frequently Asked Questions

Is bare metal Kubernetes the same as no virtualization?

Yes at the machine level: bare metal Kubernetes runs directly on physical servers with no hypervisor or guest OS. That does not mean there is no isolation; the Linux kernel provides cgroups, namespaces, and seccomp to isolate workloads without a VM boundary.

Can I run Kubernetes without kubeadm or k3s?

Yes. kubeadm and k3s are optional installers. vCluster Standalone is a CNCF-certified, single-binary control plane that runs directly on Linux without depending on kubeadm, k3s, or an external control plane cluster.

How does tenant isolation work without VMs?

Tenant isolation on bare metal uses dedicated worker nodes rather than hypervisor boundaries. With Private Nodes, each tenant cluster receives dedicated physical worker nodes, so no cross-tenant scheduling or shared kernel exposure occurs in production. For process-level sandboxing, vNode applies seccomp, cgroups, and Linux user namespaces.

What are Private Nodes in vCluster?

Private Nodes are the production default isolation model for tenant clusters. They are dedicated physical worker nodes joined privately and exclusively to a single tenant cluster, providing hardware-level tenant isolation with no shared data plane between tenants.

How does vNode isolate AI workloads?

vNode isolates AI workloads at the process level using kernel-native sandboxing: seccomp, cgroups, and Linux user namespaces. It preserves direct GPU access with near-zero performance impact and is designed for AI agent runtimes, dynamic code execution, and workloads that require root access or arbitrary package installs.

What is the fastest way to provision bare metal Kubernetes for a GPU cloud?

The fastest path combines automated physical provisioning with a single-binary control plane. vMetal automates PXE boot, OS installation, and machine registration, while vCluster Standalone provides a CNCF-certified Kubernetes control plane directly on Linux, cutting the path from rack to running tenant cluster down to days rather than weeks.

Why do AI clouds run Kubernetes on bare metal instead of VMs?

AI clouds run Kubernetes on bare metal because it eliminates the hypervisor tax, reduces tail latency, and preserves raw GPU performance. For AI inference and training, direct access to physical hardware can be the difference between meeting latency SLOs and losing margin at rack scale.

Does this approach work for tenant-isolated GPU clouds?

Yes, it is specifically designed for tenant-isolated GPU clouds. Each tenant receives an isolated control plane with its own API server, etcd, scheduler, RBAC, and Private Nodes for hardware-level isolation. This model is already running across 50+ GPU Clouds & Fortune 500s on 100K+ GPUs.