Containers and orchestration
Containers vs virtual machines
A virtual machine boots its own kernel. A container shares the host kernel. That one difference explains the speed, the size and the security trade-off.
A virtual machine (VM) imitates a whole computer. A hypervisor gives each guest its own virtual CPUs, memory and disks, and each guest boots its own kernel. A container skips the second kernel. The host's kernel runs the container's process directly. That choice drives almost every trade-off in this topic.
Concept
The kernel is the core of the operating system. It schedules processes, manages memory and talks to the hardware. Programs ask it for work through system calls.
The big idea
Think of a VM as a house with its own foundation, wiring and plumbing. A container is an apartment in a building. Each apartment has its own door and locks, but they all sit on the same foundation.
The analogy breaks at security. A house with its own foundation is hard to reach through a crack in a neighbour's wall. In a container, a bug in the shared foundation, the kernel, is a crack that every apartment shares.
Walking through the difference
| Virtual machine | Container | |
|---|---|---|
| Kernel | One per guest | Shared with host |
| Startup | Seconds to minutes | Milliseconds to about 1 s |
| Memory overhead | Hundreds of MB per guest | Roughly the process itself |
| Image size | GBs (full OS disk) | MBs to hundreds of MBs |
| Isolation boundary | Hypervisor (small, hardened) | Kernel syscall interface (large) |
| Run a different OS kernel | Yes | No (Linux containers need a Linux kernel) |
Trace a startup. A VM boots a kernel and an init system, and only then starts your app. A container skips the first two steps and starts your process. That is where the gap between seconds and milliseconds comes from.
The middle ground matters. Firecracker, the microVM monitor behind AWS Lambda and Fargate, boots a stripped-down VM in roughly 125 ms. gVisor, used by Google Cloud Run's first generation, intercepts system calls in a user-space kernel. Both exist because multi-tenant clouds do not trust a shared kernel to separate strangers. Inside your own company, plain containers are usually fine.
Note
On macOS and Windows, Docker Desktop and Podman run a small Linux VM and put your containers inside it. That is why file mounts from your Mac are slower than native, and why localhost networking sometimes behaves differently.
Common mistakes
- Calling a container a small VM. It has no kernel of its own, so it cannot run a different OS kernel.
- Assuming VM-grade isolation. The boundary is the kernel's system call interface, which is large.
- Expecting a Mac to run containers directly. Linux containers run inside a Linux VM on macOS.
Check yourself
- Why does a container start in milliseconds while a VM takes seconds? Answer: A container skips booting a second kernel, so the host kernel runs its process directly.
- Why does a kernel exploit matter more for containers than for VMs? Answer: All containers on a host share one kernel, so one kernel bug can reach them all and the host.
Key takeaways
- A VM boots its own kernel. A container shares the host kernel.
- That sharing gives containers their speed and small size, and a weaker isolation boundary.
- Linux containers need a Linux kernel, even when your laptop runs macOS.
Further learning
Next, see how a container gets its isolation from namespaces and cgroups.
Related
Containers from the inside
Namespaces, cgroups and layered images - what a container really is, how images are built and shipped, and how to write small, fast, secure Dockerfiles.
Namespaces and cgroups
A container is a Linux process with two kernel features applied. Namespaces control what it can see, and cgroups control what it can use.
Processes, threads and the kernel
What the OS gives every program, and how to see it on a live Linux box. Start here for the process model.