Skip to main content
So what are containers? Containers are lightweight, isolated user-space environments that package processes together with their network interfaces and filesystem mounts. They provide many of the same isolation guarantees you expect from virtual machines — separate processes, networking stacks, and mount points — but all containers on a host share a single operating system kernel. That shared-kernel design is what makes containers fast to start and efficient in resource usage compared with full virtual machines. Containers rely on two core Linux kernel primitives:
  • Linux namespaces — which isolate process IDs (PID), networking, mount points, inter-process communication (IPC), hostname/UTS, and user views.
  • Control groups (cgroups) — which enforce resource accounting and limits (CPU, memory, block I/O, etc.).
Containers use kernel features (namespaces and cgroups) to achieve process- and resource-level isolation. Because containers share the host kernel, they are not full virtual machines.
A slide titled "What Is A Container?" showing four illustrated container cards (each listing Processes, Network, and Mounts) above a long "OS Kernel" bar. A presenter wearing a KodeKloud t-shirt stands on the right, gesturing.
Why containers are lightweight and fast:
  • No guest OS kernel: containers share the host kernel instead of booting a separate kernel per instance.
  • Minimal overhead: runtime components focus on setting up namespaces and cgroups and starting user-space processes.
  • Rapid start/stop: launching a container is typically milliseconds to seconds, compared to minutes for a VM.
History and ecosystem overview Container technology predates Docker. Notable early and alternative projects include LXC, LXD, and LXCFS:
  • LXC/LXD — userspace tools to create and manage containers using kernel features.
  • LXCFS — a userspace filesystem to improve container behavior.
Docker originally used LXC as its low-level implementation. Around Docker 0.9.0 (2014), Docker replaced LXC with its own low-level library libcontainer. libcontainer later evolved into runC, which became the reference implementation of the OCI (Open Container Initiative) runtime specification. Modern Docker uses a layered architecture:
  • Docker (user-facing tool) interacts with containerd (a daemon).
  • containerd manages image distribution and container lifecycle.
  • containerd invokes runC (the OCI runtime) to create and run container processes.
LXC/LXD/LXCFS remain useful alternatives, but Docker’s default runtime stack today typically comprises containerd + runC under the OCI standards. Quick reference: kernel primitives and what they isolate Key terms and components Why choose containers over VMs?
  • Faster startup and lower memory/CPU overhead.
  • Easier application packaging and reproducible environments.
  • Better density — more containers can run on the same host compared to VMs.
  • Simpler CI/CD and microservices workflows due to image immutability and portability.
Links and references
If you’re learning containers, focus first on namespaces and cgroups to understand how isolation and resource limits work. Then explore higher-level tooling such as Docker, containerd, and runC to see how those primitives are composed into a usable developer workflow.

Watch Video