Physical Servers and Their Limits

Hi everyone 👋, I'm Hung Anh.

This is the second article in the Kubernetes Fundamentals series. In the previous article, we went through what a kernel, a driver, and a sandbox actually are. This time, let's dig into what a physical server actually looks like, and why we can't just keep deploying more onto the same one.

Let's get started.

1. What's Inside a Physical Server?

A physical server is just a real computer — an actual box sitting in a datacenter (or, for a lot of us right now, a laptop or a rented VPS standing in for one). Everything it runs sits on top of the exact same stack we already met in the last article:

• Hardware — the CPU, RAM, disk, and network card actually doing the work.
• Kernel — the only thing allowed to talk directly to that hardware.
• Drivers — the kernel's translators for each specific piece of hardware.
• OS (Operating System) — the kernel plus everything shipped alongside it: a shell, a package manager, system services — the layer that makes the machine actually usable.
• Application — what we actually deploy and want running: an API, a background worker, whatever the job is.

Every one of those layers, from the app you deploy down to the disk it writes to, sits on exactly one kernel, running on exactly one set of physical hardware. That single fact is the whole limitation this article is about.

2. The Limits of a Physical Server

Say you need to deploy a web application. The simplest path: rent or buy one physical machine, install an OS, deploy the app onto it. That works fine — for a while.

• Most of that machine sits idle. Studies of typical x86 servers have found average CPU utilization sitting around just 10-15%. The other 85-90% is capacity you already paid for, and it's simply not being used. It can't be lent out either — there's only one kernel here, running one workload, with nothing else to hand that idle capacity to.
• One machine, one environment. Say a second app needs a different environment — a different OS version, or a library version that conflicts with what the first app is already using. You can't just drop it onto the same kernel: that kernel is already running one specific OS version — it can't run that version for the first app and a different one for the second app at the same time. The only option is another physical machine.
• Scaling is slow. Traffic spikes, you need more capacity — buying, racking, and cabling another physical machine takes days to weeks, not the minutes an actual spike gives you.
• Everything on it fails together. One machine, one point of failure. If the hardware dies, every app running on it goes down with it, at the same time.

Here's the question all of this leads to: is there a way for a single piece of physical hardware to run several different, isolated environments at once — and actually use that idle 85% instead of letting it sit there unused?

That's exactly the idea behind the virtual machine (VM). How it solves this is what the next article picks up.

3. Summary

A physical server is one kernel, bolted directly to one set of hardware, running whatever OS was installed on it. That's simple, but it comes with real limits: most of its capacity sits idle and can't be shared, it can only run one OS/environment at a time, and scaling it means physically buying and racking more hardware.

Time to relax for a bit, then join me in the next article on virtual machines — let's see how they solve this problem, and what downsides come with them.

Happy reading! 🍵

References

1. The history of virtualization and its mark on data center management - TechTarget
2. What is Server Utilization Rate? A Guide to Data Center Efficiency - Hyperview