1.3.1.2 Kernel Sharing Contrast

Kernel sharing contrast focuses specifically on the consequence of Docker containers using the host's single kernel instance, as opposed to virtual machines, where each guest runs its own independent kernel — a distinction that affects compatibility, security boundaries, and what kinds of workloads each technology can run.

One Kernel, Many Containers

Every container on a given Docker host executes on top of the same running kernel. The kernel is what provides the namespaces and cgroups that isolate containers from one another, but it remains a single shared resource underneath all of them.

uname -r
docker run --rm alpine uname -r

Running this on the host and inside a container produces the same kernel version, because the container is not running its own kernel — it is observing the host's.

Compatibility Implications

Because containers depend on the host kernel, a container built for Linux requires a Linux kernel to run. This is why Windows containers and Linux containers are not interchangeable on the same Docker engine instance without switching which kind of container runtime is active, and why Docker Desktop on macOS and Windows runs a lightweight Linux virtual machine specifically to provide a Linux kernel for Linux containers.

docker info --format '{{.OSType}}'

Kernel Version Constraints

A container generally cannot make use of kernel features newer than what the host kernel actually provides, regardless of what the container's own userland might otherwise support, since kernel-level functionality comes entirely from the host.

docker run --rm alpine cat /proc/version

Security Boundary Consequences

Because all containers on a host rely on the same kernel for their isolation guarantees, a vulnerability that allows a process to escape its namespace or cgroup confines can potentially affect other containers on the same host — a risk that does not apply between separate virtual machines, each running its own kernel instance.

Why Kernel Sharing Is Still the Right Tradeoff for Many Workloads

Despite this security tradeoff, kernel sharing is what makes containers fast to start and cheap to run in large numbers, since no additional kernel needs to be booted or maintained per workload. For workloads that trust each other or are otherwise sufficiently isolated by other means (network policy, a properly maintained host, limited privilege containers), the efficiency gain typically outweighs the narrower isolation boundary.

docker run --security-opt=no-new-privileges --read-only myapp:1.0