Container technology is a Linux kernel feature set: namespaces (PID, network, mount, UTS, IPC, user - each container sees its own process tree, network stack, etc.), cgroups (resource limits - CPU, memory, I/O per container), and UnionFS (layered filesystems - copy-on-write, shared base layers). The userspace tools (runc, containerd, Docker, Podman) orchestrate these. The team that understands the kernel features understands why containers work the way they do - and why they are not the same as VMs.
Table of contents
- The three kernel features
- Why namespaces work
- Why cgroups work
- Why UnionFS works
- The userspace tools
- Why containers are not VMs
- How this fits the rest of the stack
- FAQ
The three kernel features
Namespaces - what a container can SEE. Each container has its own PID namespace (its own process tree, starting at PID 1), its own network namespace (its own interfaces, routing table, firewall), its own mount namespace (its own filesystem view), and others. The container cannot see the host’s processes, network, or filesystem (unless explicitly shared).
cgroups (control groups) - what a container can USE. Each container has limits on CPU, memory, I/O bandwidth, network bandwidth, and process count. The kernel enforces these limits - the container can use up to its limit, no more.
UnionFS (Union Filesystem) - how a container’s filesystem is BUILT. Each image layer is a directory; layers are stacked with copy-on-write. The container sees a single unified filesystem, but the underlying storage is shared and efficient.
Why namespaces work
Namespaces were added to Linux in 2002 (mount namespace), 2006 (PID, network, UTS, IPC), and 2008 (user). The point: a process in a namespace only sees what is in that namespace.
Example: a process in PID namespace A sees only its own PIDs (1, 2, 3, …). A process in PID namespace B sees only its own PIDs. The same process in the host’s PID namespace sees both containers’ processes. The team that uses ps aux inside a container sees the container’s processes, not the host’s - because the container is its own PID namespace.
The same applies to network: a container’s eth0 is a virtual interface in the container’s network namespace. The host’s eth0 is a different interface in the host’s network namespace. They are not the same - they are linked by a virtual bridge or a veth pair.
Why cgroups work
cgroups were added to Linux in 2008. The point: limit, account for, and isolate resource usage (CPU, memory, disk I/O, network, etc.) of a process or a group of processes.
Example: a container configured with --memory=512m and --cpus=1.0 has a cgroup that limits it to 512 MB of memory and 1 CPU’s worth of compute. The kernel enforces these limits - the container can use up to the limit, then is throttled (CPU) or OOM-killed (memory).
The team that has a container that mysteriously dies at 3 AM checks dmesg for OOM-kill events on the container’s cgroup.
Why UnionFS works
UnionFS layers:
Container view: /
├── bin/ (from base layer)
├── etc/ (from container layer, overlay on base)
├── usr/ (from base layer)
└── var/ (from container layer, overlay on base)
Each image layer is a directory. When the container writes a file, the write goes to the container’s writable layer (copy-on-write). When the container deletes a file, the deletion is recorded in the writable layer; the file still exists in the base layer. When the container reads a file, the kernel looks it up in the writable layer first, then the base layers.
The team that builds images with many layers has efficient storage (shared base layers, only differences in the container layer). The team that uses one giant layer loses this efficiency.
The userspace tools
runc - the low-level runtime. Implements the OCI (Open Container Initiative) spec. Takes a container config and runs it (namespaces, cgroups, rootfs). The team that uses Kubernetes uses runc via containerd or CRI-O.
containerd - the higher-level runtime. Pulls images, manages container lifecycle, exposes a gRPC API. Used by Docker, Kubernetes (via kubelet), and others.
Docker, Podman, nerdctl - the CLI tools. Talk to containerd, runc, or the kernel directly. The team that uses one of these is the team that runs containers.
Kubernetes - the orchestrator. Schedules containers across a cluster, manages networking, storage, scaling. The team that runs a single host does not need Kubernetes; the team that runs many hosts does.
Why containers are not VMs
A VM has its own kernel. A container shares the host’s kernel. The implications:
-
VM startup: 10-60 seconds (BIOS, bootloader, kernel, init, services).
-
Container startup: 10-100 ms (just process spawn with namespace setup).
-
VM isolation: full kernel isolation. A kernel exploit in the VM does not affect the host.
-
Container isolation: kernel shared. A kernel exploit in the container can affect the host (gVisor and Kata mitigate this).
-
VM size: GB (the OS, plus the app).
-
Container size: MB-tens of MB (just the app and its deps).
The team that needs full kernel isolation (multi-tenant untrusted workloads) uses VMs or gVisor/Kata. The team that needs fast startup and small size uses containers.
FAQ
Do containers have their own kernel?
No - they share the host’s kernel. This is what makes them fast and small. The trade-off: a kernel exploit in a container can affect the host. gVisor and Kata Containers add a layer of isolation by running a user-space kernel or a lightweight VM.
What is the difference between OCI and Docker?
OCI (Open Container Initiative) is the standard for container formats and runtimes. Docker contributed the spec that became OCI. runc is the OCI reference implementation. Docker uses runc (or containerd, which uses runc). The team that uses the OCI standard can swap runtimes without changing images.
Can I run a different Linux distro inside a container?
Yes - the container’s user space is whatever the image provides. The kernel is the host’s. The team that runs ubuntu:22.04 on a rhel:9 host has Ubuntu userspace + RHEL kernel. This works because the kernel ABI is stable; userspace can be any distro that targets that kernel.
Why is container isolation weaker than VM isolation?
Containers share the host’s kernel. A kernel vulnerability is a host vulnerability. VMs have their own kernel, so a kernel vulnerability in one VM does not affect the host. The team that needs VM-grade isolation uses gVisor, Kata Containers, or actual VMs.
What is the difference between cgroups v1 and v2?
cgroups v1 is the original API, with separate hierarchies for each resource. cgroups v2 (unified hierarchy) is the newer API, with a single hierarchy and better resource isolation. Modern Linux distros ship cgroups v2 by default (since systemd 250, 2021). The team that runs Kubernetes on a modern distro has cgroups v2.
How this fits the rest of the stack
For a sense of what the full project costs before it commits, the RunxBuild hosting calculator shows the line items together. The API, the database, the storage, the worker, the bandwidth - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers.
Useful related references: