VM vs Kubernetes, and what a cluster actually is

The two ways to ship a thing, side by side: one you tend by hand for years, one you declare and forget.

Before you start. Two ideas from earlier lessons, in one line each. A team soon needs more than one machine, and a group of machines run together is a fleet (From One Crate to a Fleet (why Kubernetes)). And you can write down what the fleet should be running and let a background loop keep making that true, even when machines die (The Harbor Master (pods, deployments, services)). This lesson assumes both and spends its length on the question they skip: a VM and a container both claim to isolate your app, so what do you actually trade choosing between them, and when is the fleet not worth having at all? If a process and the kernel are new, Processes, Threads & the Kernel in How Computers Work shows them in one read.

The idea in 30 seconds

A VM and a container aren’t two sizes of the same box: a VM gets its own kernel, a container shares the host’s.
The hypervisor gives each VM a body of its own; a namespace and a cgroup only tag and fence a process standing on somebody else’s body.
A kernel bug is a hole in every container’s fence at once - that’s why platforms running strangers’ code still put a VM, or a fast one like Firecracker, underneath.
Containers are cheap because they share; VMs are safer because they don’t. There’s no version of this trade you get out of.
A cluster turns “which machine runs this” into “how much does this need” - a scheduler bin-packs jobs onto a herd, and that’s the whole idea of Kubernetes.
All of that costs real dollars, minutes, and legible failures, and most of the time one well-tended pet is still the right animal to own.

Read the story · Skip to the numbers