7 Ways to Run EKS on Bare Metal Without the Hypervisor Tax

Summary

• Running Kubernetes on bare metal for GPU workloads presents a trade-off: accept the high operational complexity of tools like EKS Anywhere or the performance penalty of a hypervisor.
• This article evaluates 7 patterns for bare metal Kubernetes, from DIY kubeadm to enterprise platforms like OpenShift, comparing them on operational overhead, tenant isolation, and GPU performance.
• For teams building AI clouds with strong tenant isolation, virtualizing the Kubernetes control plane offers the strongest balance of isolation and performance, avoiding the high cost of dedicating physical clusters per tenant. The vCluster Platform enables this by creating fully isolated tenant clusters as lightweight pods.

You've maxed out your cloud bill, your GPU-hungry AI workloads are screaming for more performance, and someone in the architecture meeting finally says it: "We should just run this on bare metal." Everyone nods. Then the follow-up question lands: "So… do we use EKS Anywhere?"

And that's where the trouble starts.

EKS Anywhere is the obvious AWS-native answer for running Kubernetes on your own hardware. But as countless teams have discovered — often the hard way — it comes with a deceptive amount of operational complexity. You're not just running clusters; you're managing the entire Tinkerbell bare metal provisioning stack, handling DHCP reservations and PXE boot intricacies, and maintaining a dedicated management cluster just to keep the lights on for your workload clusters. As one engineer put it plainly on Reddit: "it seems these solutions involve managing our own infrastructure, losing the benefits of fully-managed EKS on AWS."

That's the core tension: you want bare metal performance — especially for GPU workloads — but every path to getting there seems to introduce its own flavor of operational pain.

Then there's the hypervisor tax: the performance penalty and licensing overhead you incur when a virtualization layer (VMware vSphere, Hyper-V, KVM) sits between your hardware and your Kubernetes workloads. For CPU-bound services, you might not notice. For NVIDIA GPU training runs, it's a measurable throughput hit — and an unnecessary one.

This article examines 7 distinct patterns for running Kubernetes on bare metal, evaluating each pattern on:

• Operational complexity — How much do you need to manage day-to-day?
• Tenant isolation quality — How well are different workloads or customers separated?
• GPU performance preservation — Does this approach actually eliminate the hypervisor tax?

We'll be honest about the trade-offs, and close with a decision matrix to help you pick the right path for your team.

1. vCluster Standalone: The Zero-Dependency K8s Distribution

Operational Complexity: Low | Tenant Isolation: Very High | GPU Performance: Excellent

Most "bare metal Kubernetes" setups still require a base distribution — k3s, kubeadm, k0s — before you can do anything useful. vCluster Standalone eliminates that dependency entirely. It's a CNCF-certified Kubernetes distribution that ships as a single binary and runs directly on a Linux OS — no existing cluster required, no bootstrapping dance.

The control plane (API server, controller manager, etcd) runs as a lightweight process on your infrastructure. Worker nodes join securely, and you're running certified Kubernetes in minutes. When combined with the vCluster Platform, you can then provision fully isolated tenant clusters as lightweight pods — virtualizing the Kubernetes control plane itself rather than carving out namespaces or spinning up full physical clusters per tenant.

Resource requirements for a dev/test setup: 0.2 vCPU, 512 MiB RAM, 1 GiB ephemeral storage. Production deployments scale accordingly.

For bare metal GPU fleets, vMetal extends Standalone with zero-touch provisioning — PXE boot, OS install, machine registration, network automation — creating the complete path from GPU rack to managed Kubernetes without intermediate dependencies. vNode (currently in private beta) adds kernel-native workload isolation (seccomp, cgroups, namespaces, AppArmor) for container breakout protection at bare metal speed.

What breaks at scale: As a commercial product, it introduces a vendor relationship. However, the core vCluster technology is open source with 30.1k GitHub stars, and the platform is production-proven at 100K+ GPU nodes across 50+ GPU clouds and Fortune 500 customers including CoreWeave and JPMorganChase.

Best for: Neoclouds and AI cloud providers who need to go from bare metal racks to a managed Kubernetes offering with tenant isolation — fast. Lintasarta launched Indonesia's leading GPU cloud in 90 days with 170+ tenant clusters using this stack.

2. EKS Anywhere with Tinkerbell: The AWS-Native Path

Operational Complexity: High | Tenant Isolation: High | GPU Performance: Good

EKS Anywhere is AWS's official answer for running Kubernetes on your own hardware. For bare metal specifically, it relies on Tinkerbell — an open-source provisioning engine — to handle OS installation and machine bootstrapping via PXE.

The architecture works like this: a temporary kind-based bootstrap cluster provisions a permanent management cluster, which then uses Tinkerbell and Cluster API to provision and manage workload clusters on your bare metal servers. It's declarative, GitOps-friendly, and deeply integrated with the AWS ecosystem (IAM, ECR, CloudWatch).

But the operational reality is sobering. You're responsible for the health of multiple Tinkerbell services (Hegel, Tink, Boots), DHCP lease management, PXE boot configuration, and the management cluster itself — which becomes a single point of failure. Debugging a failed provisioning run through the Tinkerbell stack is not a quick Friday afternoon task.

What breaks at scale: The management cluster overhead grows as you add workload clusters. GPU driver and runtime management across the fleet via Cluster API adds another layer of operational surface area.

Best for: Teams already deeply embedded in the AWS ecosystem who need native integration with IAM and AWS tooling, and have the ops maturity to manage the full Tinkerbell stack.

3. Kubeadm DIY: The "From Scratch" Standard

Operational Complexity: High | Tenant Isolation: Low–Moderate | GPU Performance: Good

kubeadm is the Kubernetes project's own tool for bootstrapping a minimal, production-viable cluster. You provision Linux servers, install a container runtime, run kubeadm init on a control plane node, and kubeadm join on workers. That's the easy part.

Everything else is on you: CNI plugin selection and configuration, storage drivers, certificate management, HA topology, and — crucially — upgrades. Certificate rotation alone is a recurring operational event that trips up teams regularly. For tenant isolation, you're typically relying on namespaces, which provide weak isolation — shared API server, shared blast radius, noisy neighbor risk.

What breaks at scale: Day 2 operations don't scale linearly — they scale exponentially. Managing 3 clusters with kubeadm is manageable. Managing 30 is a full-time job for multiple engineers.

Best for: Teams that need maximum control over every component and want a deep understanding of Kubernetes internals. Often a starting point, but rarely a long-term destination at scale.

4. k3s DIY: The Lightweight Edge-Focused Option

Operational Complexity: Medium | Tenant Isolation: Low–Moderate | GPU Performance: Moderate–Good

k3s from Rancher/SUSE is a CNCF-certified Kubernetes distribution packaged as a single binary under 100MB. It bundles containerd, Traefik for ingress, and uses SQLite by default for single-node setups (or etcd for HA). Getting a cluster running is remarkably fast — often under five minutes.

It's a popular choice as a base layer for more complex setups, and it handles GPU workloads reasonably well. But "simple to start" doesn't mean "simple to run at scale." k3s is still a DIY approach: you own the infrastructure, the upgrades, and the tenant isolation story (which, again, defaults to namespaces).

What breaks at scale: Advanced GPU scheduling, complex network policies, and enterprise-grade fleet management require significant additional tooling on top. k3s wasn't designed for 500-node GPU clusters serving hundreds of tenants.

Best for: Edge deployments, smaller-scale on-prem clusters, or as a lightweight base for development environments. A reasonable step up from kubeadm for teams prioritizing simplicity over configurability.

5. OpenShift on Bare Metal: The Enterprise-Grade Platform

Operational Complexity: Medium–High | Tenant Isolation: High | GPU Performance: Good

Red Hat OpenShift is a fully integrated enterprise Kubernetes platform that runs on Red Hat Enterprise Linux CoreOS (RHCOS). The installer automates a significant amount of the bootstrap process — DNS, DHCP, OS provisioning — and the result is a cohesive, fully supported platform with built-in developer tooling, a strong RBAC model, and Projects (namespaces with enhanced security policies).

OpenShift has a validated stack for GPU workloads through OpenShift AI and strong NVIDIA partnership, making it a credible option for enterprises building internal AI platforms.

What breaks at scale: Licensing costs are significant — OpenShift is not cheap. The platform is highly opinionated, which is a strength if your needs align with Red Hat's prescriptions and a frustration if they don't. Resource consumption for the platform components themselves is substantial.

Best for: Enterprise organizations already invested in the Red Hat ecosystem that need a fully supported, integrated platform with a single vendor behind it.

6. VMware Tanzu on Bare Metal: The Virtualization Incumbent

Operational Complexity: High | Tenant Isolation: High | GPU Performance: Moderate

VMware Tanzu Kubernetes Grid (TKG) follows a familiar pattern: a management cluster (built on Cluster API) provisions and manages workload clusters. It's designed to provide a consistent Kubernetes experience across vSphere, bare metal, and cloud environments.

The challenge is that VMware's DNA is virtualization. Even when deployed on bare metal, Tanzu often nudges operators toward vSphere-based infrastructure, which re-introduces the hypervisor tax this article is trying to avoid. GPU passthrough in vSphere environments requires careful configuration and typically delivers lower performance than true bare metal access.

What breaks at scale: High licensing costs, significant complexity for teams without deep VMware expertise, and a product roadmap that has been complicated by Broadcom's acquisition. Many teams are actively evaluating replacements.

Best for: Organizations with existing deep VMware investments and expertise who need a supported path to Kubernetes without abandoning their current infrastructure management paradigm.

7. Physical Clusters Per Tenant: The Brute-Force Isolation Method

Operational Complexity: Very High | Tenant Isolation: Very High | GPU Performance: Excellent

The conceptually simplest approach to tenant isolation: give every tenant their own dedicated physical cluster on dedicated hardware. No shared API server, no shared nodes, no shared anything.

The isolation is ironclad. The GPU performance is uncontested. And the operational cost is staggering.

You're managing N distinct physical clusters, each with its own lifecycle, certificate rotation, upgrade path, monitoring stack, and provisioning pipeline. As the number of tenants grows, so does the fleet management burden — linearly at best. Hardware utilization is typically poor, because dedicated clusters sit partially idle but can't share capacity.

What breaks at scale: Everything. Management overhead, hardware costs, time to provision a new tenant (days, not minutes), and the inevitable configuration drift across dozens of "identical" clusters.

Best for: Highly regulated environments (financial services, defense) where physical isolation is a hard compliance requirement and cost is secondary. Not a practical model for neoclouds or AI cloud providers serving many customers.

Decision Matrix: Which Pattern Fits Your Profile?

The pattern that threads the needle most cleanly for teams building AI clouds or GPU-intensive internal platforms is vCluster Standalone. It eliminates the base-layer dependency — no k3s, no kubeadm required before you can start — delivers a CNCF-certified Kubernetes distribution directly on Linux, and provides a clear upgrade path to full tenant cluster orchestration with the vCluster Platform. For GPU tenant isolation specifically, it avoids the resource underutilization of physical clusters per tenant while delivering far stronger isolation than namespace-based approaches.

The Bottom Line

Running Kubernetes on bare metal forces a real trade-off: accept the hypervisor tax and lose GPU performance, or take on the operational complexity of managing raw infrastructure. There's no free lunch — but there are better and worse deals.

EKS Anywhere is the right call if you need deep AWS integration and have the ops bandwidth to manage the Tinkerbell stack. kubeadm and k3s are reasonable starting points if you're building skills and don't yet know your scale requirements. OpenShift earns its cost in enterprises that need a fully integrated, supported platform. Physical clusters per tenant make sense when physical isolation is a non-negotiable compliance requirement.

But if you're building an AI cloud, launching a managed GPU Kubernetes offering, or trying to squeeze maximum utilization out of expensive bare metal hardware — the path that eliminates the most unnecessary complexity is a zero-dependency Kubernetes distribution that runs directly on Linux, with tenant cluster orchestration and workload isolation built on top.

vCluster Standalone is that path. Follow the deployment guide to see how quickly you can go from bare metal to a running, certified Kubernetes cluster — no intermediate base layer required.

Frequently Asked Questions

What is bare metal Kubernetes?

Bare metal Kubernetes refers to running a Kubernetes cluster directly on physical servers without any underlying hypervisor or virtualization layer. This provides direct access to the hardware's full performance capabilities. Unlike running Kubernetes on virtual machines (VMs), this approach eliminates the "hypervisor tax"—the performance overhead associated with virtualization—which is especially beneficial for GPU-intensive workloads like AI model training.

Why choose bare metal Kubernetes over a managed cloud service like EKS?

Teams choose bare metal Kubernetes primarily for superior performance, lower long-term costs, and greater control over their hardware and network environment. It allows them to bypass the performance penalties and pricing models of public cloud providers. For GPU-heavy AI workloads, the performance gains from eliminating the hypervisor can be substantial, and running on your own hardware can significantly reduce costs at scale, though it requires taking on more operational responsibility.

What is the "hypervisor tax" and why does it matter for GPUs?

The "hypervisor tax" is the performance overhead incurred by the virtualization layer that sits between your application and the physical hardware. For GPUs, this tax can manifest as reduced throughput and increased latency, directly impacting the speed and cost of AI model training. Eliminating this layer by running on bare metal ensures that Kubernetes workloads get raw, uncontended access to the GPU's full power.

How does vCluster provide strong tenant isolation on a shared cluster?

vCluster provides strong tenant isolation by virtualizing the Kubernetes control plane itself, giving each tenant a dedicated API server within a lightweight pod. This is far more secure and isolated than traditional namespace-based multi-tenancy. Because each tenant has their own control plane, they are effectively sandboxed from other tenants, preventing noisy neighbor problems or security cross-talk without the high cost of dedicating physical hardware per tenant.

Is EKS Anywhere the same as EKS on AWS?

No, EKS Anywhere is not a fully managed service like EKS on AWS. While it provides an AWS-consistent Kubernetes distribution, you are fully responsible for managing the underlying hardware, operating system, and the entire EKS Anywhere control plane stack. For bare metal, this involves managing the complex Tinkerbell provisioning stack and a dedicated management cluster—a significant operational burden compared to its managed cloud counterpart.

What is the biggest challenge of moving to bare metal Kubernetes?

The biggest challenge is the significant increase in operational complexity. You become responsible for everything a cloud provider normally handles, from hardware provisioning and OS installation to network configuration and cluster lifecycle management. Tasks like setting up PXE booting, managing DHCP, rotating certificates, and performing cluster upgrades become your team's responsibility, which is why choosing a solution that simplifies this process is critical for success at scale.

‍