Explains how Docker containers reuse the host Linux kernel, isolate userlands using namespaces and cgroups, use layered filesystems, and differ from virtual machines.
To understand how Docker works, we first revisit a few core operating system concepts that Docker builds on.Most Linux distributions — for example Ubuntu, Fedora, openSUSE, or AlmaLinux — are composed of two main layers: the kernel and the userland (user-space) software. The kernel interacts with the hardware and provides core OS services (process scheduling, memory management, device drivers, networking). The userland includes shells, libraries, package managers, GUIs, and developer tools. In the Linux ecosystem the kernel family (Linux) is shared across distributions; what differentiates distributions is the userland software stack.Because distributions share the same kernel, Docker containers take advantage of that by packaging only the userland components an application needs. Containers reuse the host kernel while providing each container an isolated user-space environment.A quick comparison:
Component
Responsibility
Example
Kernel
Hardware interaction, process and memory management, system calls
Because the host provides the kernel, a Linux host running Docker can start containers whose images contain userlands from Debian, Fedora, openSUSE, AlmaLinux, or other distributions. Each container includes the user-space libraries, binaries, and configuration that define its environment; the container processes run on the host kernel but inside isolated userland namespaces.This isolation is provided by kernel primitives:
Namespaces — isolate process IDs, mount points, network stacks, UTS (hostname), IPC, and user IDs so container processes see their own environment.
Control groups (cgroups) — enforce resource limits and accounting for CPU, memory, block I/O, and more.
Union file systems (overlayfs, AUFS, etc.) — enable layered, copy-on-write images to keep containers lightweight.
What happens when the host and container kernels differ — for example, Windows vs Linux? A Linux host cannot natively run a Windows container because Windows uses a different kernel.
A Linux kernel cannot execute Windows kernel binaries. To run Windows containers you need Docker on a Windows host that provides the Windows kernel.
You may, however, have seen Docker start a Linux container on a Windows machine. In that case Docker Desktop provisions a small Linux environment so the container can access a Linux kernel. Historically this used Hyper-V; modern Docker Desktop often uses the Windows Subsystem for Linux 2 (WSL2) backend. The practical effect is: the Linux container runs inside a Linux VM that itself runs on Windows.
$ docker run linux-image✓ Linux container started
Docker Desktop uses a lightweight Linux VM (or WSL2 on modern Windows) so Linux containers can run on non-Linux hosts. On macOS Docker Desktop similarly runs a small Linux VM. This is why Docker commands behave the same cross-platform even when the host OS differs.
Does kernel-sharing limit Docker? Not for its intended use cases. Docker is not a hypervisor replacement for running unrelated kernels concurrently; hypervisors virtualize hardware so you can run different kernels and full OSes side-by-side. Docker’s strength is packaging applications and their dependencies into lightweight, portable containers that:
Start faster than VMs
Use less disk and memory
Are easier to distribute and deploy
For workloads that require complete OS isolation or different kernels, use a virtualization solution (hypervisor). For application packaging, consistent runtime environments, and efficient resource usage, containers are usually the better option.Comparison: containers vs hypervisors
