> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# How Docker Works
> 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 | Linux kernel (shared across distros) |
| Userland | Libraries, binaries, package managers, configuration | `systemd`, `apt`, application binaries |
Sharing the kernel.
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.
```bash theme={null}
$ 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
| Feature | Containers | Hypervisors (VMs) |
| - | - | - |
| Kernel | Shares host kernel | Runs guest kernel |
| Startup time | Typically milliseconds to seconds | Seconds to minutes |
| Resource overhead | Low (userland only) | Higher (full OS per VM) |
| Use case | App packaging, microservices, CI/CD | Running different OSes, full isolation |
Further reading and references:
* [Docker Documentation](https://docs.docker.com/)
* [Linux namespaces](https://man7.org/linux/man-pages/man7/namespaces.7.html)
* [cgroups v2](https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html)
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.