a container

A container is a lighter form of isolation than a virtual machine: instead of running a whole separate operating system, a container is just a group of processes on the host that are given their own private, walled-off view of the system while secretly sharing the host's single kernel. Picture an open-plan office where everyone shares the same building and air conditioning (the kernel), but each team is given a partitioned area with its own door, its own labelled supplies, and a fixed budget of desks — they feel like they have their own office, but the building underneath is one.

Technically, a container is built from two ordinary kernel features. Namespaces give the container its isolated view: its own process numbers (so it sees only its own processes), its own file-system root, its own network interfaces, its own user IDs, so that from inside it looks like a fresh machine. Control groups (cgroups) put limits on what it can consume: this much CPU, this much memory, this much I/O bandwidth, so one container cannot starve the others. Add a layered file-system image (an overlay) that bundles the app and its libraries, and you have a container: a portable, self-contained unit that runs the same way anywhere the same kernel does.

Containers matter because they are fast and cheap compared with VMs: there is no second operating system to boot, no virtual hardware to emulate, so a container starts in a fraction of a second and uses far less memory, which is why they pack densely and underpin modern cloud deployment. The honest trade-off is isolation strength: because every container shares the one host kernel, a flaw that lets code escape the kernel breaks every container at once — whereas a VM has its own kernel and an extra hypervisor boundary. Containers are lighter and faster; VMs are more strongly isolated.