Table of Contents:
- What Is Kubernetes on Bare Metal?
- Benefits of Bare-Metal Kubernetes
- Why Not to Run Kubernetes on Bare Metal
- When — and When Not — to Run Kubernetes on Bare Metal
Living as we do in the world of software-defined everything, it might seem archaic to consider running Kubernetes on bare metal instead of using virtual machines. Yet there remain good reasons to consider bare-metal Kubernetes clusters.
Keep reading for a look at the benefits — as well as the drawbacks — of operating Kubernetes on bare metal.
What Is Kubernetes on Bare Metal?
Running Kubernetes on bare metal means using bare-metal servers as Kubernetes control plane and worker nodes. It's the opposite of relying on virtual machines to serve as nodes.
With bare-metal Kubernetes, then, you take virtualization out of the equation. You still run your applications inside containers, but you don't need virtual machines, guest operating systems, and hypervisors to create the infrastructure that hosts those containers.
Benefits of Bare-Metal Kubernetes
Why would you want to run Kubernetes on bare metal? Well, for several potential reasons:
Performance
Probably the strongest argument for bare-metal Kubernetes is that it can improve workload performance. The main reason why is that by removing hypervisors and guest operating systems from your stack, you don't have to expend resources powering those components. As a result, you have more CPU and memory available for your applications.
Direct access to hardware
Certain workloads can take advantage of Kubernetes on bare metal to access hardware components, such as GPUs, that are difficult or impossible for Kubernetes-based applications to leverage when running on virtual machines. This makes bare-metal Kubernetes especially useful for workloads, such as some AI/ML applications, that can benefit from GPU offloading.
Simplicity
There's an argument to be made that Kubernetes on bare metal simplifies administration because it reduces the total number of nodes you have to manage. Rather than taking a pool of physical servers and breaking each one into multiple nodes, bare-metal Kubernetes leaves you with a smaller overall group of nodes. That translates to less node provisioning, fewer node logs and metrics to protect, fewer node security risks to manage, fewer node updates to deploy, and so on.
Why Not to Run Kubernetes on Bare Metal
On the other hand, there are good reasons why you might opt for virtual machines over bare-metal Kubernetes.
Resilience
Nodes that are created using VMs add resilience to your Kubernetes clusters because the failure of a single VM will deprive the cluster only of the resources allocated to that VM. Other VMs hosted on the same underlying server would remain available (assuming the failure resulted from a problem with the VM and not the host server, of course).
In contrast, if your nodes are bare-metal servers, a single server's failure is likely to have a larger impact on your overall cluster health.
Resource allocation
VMs make it easier to slice-and-dice physical servers into smaller units of resources. When used in conjunction with Kubernetes DaemonSets, which let you control which nodes run which pods, the flexible resource allocation of VMs means you get more control over how many resources are effectively available to each pod.
Less noisy neighbors
By a similar token, VMs can help reduce the "noisy neighbor" issue in Kubernetes — which means the risk that some workloads will consume too many resources and deprive others of the resources they need to run. If you divide your cluster into VMs, a "noisy" pod generally won't impact as many other pods because there will be fewer pods sharing the VM node than there would be if the node were a higher-capacity bare-metal server.
You can also, of course, use features like Kubernetes limits to help mitigate this issue; in fact, limits are a better way to manage noisy neighbor problems in Kubernetes. But VMs provide a second layer of protection.
Node uniformity
On the whole, it's likely to be easier to achieve consistent configurations if all of your nodes are VMs than if your nodes are bare-metal servers. With VMs, you can more easily provision all nodes with the same operating system and the same settings.
You could do that with bare-metal servers as well if you wanted, but reinstalling an operating system and managing its configuration settings is typically more work when you're dealing with actual hardware than with virtual machines.
Conclusion: When — and When Not — to Run Kubernetes on Bare Metal
You can sum up the pros and cons of bare-metal Kubernetes as follows: Running Kubernetes on bare-metal nodes makes most sense for use cases where performance is your chief priority. A desire to simplify things by reducing total node count is also a factor in favor of bare-metal K8s. And if you need direct GPU access, you'll want to stick with bare metal.
But in most other cases, virtual machine nodes make more sense. They're more flexible and, in general, more resilient than Kubernetes clusters running on bare-metal nodes.
About the author
Christopher Tozzi is a technology analyst with subject matter expertise in cloud computing, application development, open source software, virtualization, containers and more. He also lectures at a major university in the Albany, New York, area. His book, “For Fun and Profit: A History of the Free and Open Source Software Revolution,” was published by MIT Press.
