Virtual machines virtualize hardware—they create the illusion of complete computers with their own CPUs, memory, and devices. But what if we don't need separate kernels? What if we just want isolated environments for applications, sharing a single operating system kernel?

OS-level virtualization, most commonly known as containerization, provides exactly this. Instead of virtualizing hardware, containers virtualize the operating system, creating isolated user-space environments that share the host kernel. This approach is lighter, faster, and more efficient than full virtualization—at the cost of some flexibility and isolation guarantees.

Understanding containers is essential for modern software engineering. From Docker and Kubernetes to cloud-native architectures and microservices, containerization has reshaped how we build, deploy, and scale applications.

The fundamental difference between containers and virtual machines lies in what they virtualize:

Virtual Machines:

• Virtualize hardware (CPU, memory, devices)
• Each VM runs a complete operating system with its own kernel
• Hypervisor mediates access to physical resources
• Strong isolation through hardware boundaries

Containers:

• Virtualize the operating system (processes, filesystem, network)
• All containers share the host kernel
• Kernel mechanisms (namespaces, cgroups) provide isolation
• Lighter weight but weaker isolation than VMs

When to Use Each:

Choose Virtual Machines when:

• You need to run different operating systems (Windows on Linux host)
• Strong isolation is critical (multi-tenant security requirements)
• You need kernel-level access or custom kernels
• Legacy applications require specific OS versions
• Hardware device access or GPU pass-through is needed

Choose Containers when:

• All workloads can share the host kernel (Linux containers on Linux)
• Fast startup and high density are priorities
• Microservices architecture with many small services
• CI/CD pipelines needing ephemeral environments
• Resource efficiency is paramount

Namespaces are a Linux kernel feature that partition system resources so that a set of processes sees only an isolated subset. Namespaces are the primary mechanism for container isolation—they make a container believe it's running on its own system.

Available Namespace Types:

How Namespaces Work:

Namespaces are created via the clone() system call with specific flags, or existing processes can join namespaces via setns(). The unshare() call allows a process to disassociate from its current namespaces.

// Create a child process with new namespaces
clone(child_func, stack, 
    CLONE_NEWPID |   // New PID namespace
    CLONE_NEWNET |   // New network namespace
    CLONE_NEWNS |    // New mount namespace
    CLONE_NEWUTS |   // New UTS namespace
    CLONE_NEWIPC,    // New IPC namespace
    args);

PID Namespace in Detail:

In a new PID namespace:

• The first process becomes PID 1 (the container's init)
• PIDs inside the namespace are independent of outside PIDs
• A process has different PIDs in different namespaces

Host PID namespace:         Container PID namespace:
┌─────────────────────┐     ┌─────────────────────┐
│ PID 1 (systemd)     │     │ PID 1 (container    │
│ PID 1234 (docker)   │────▶│      init)          │
│ PID 1235 (containerd)│    │ PID 2 (app)         │
│ PID 1240 (container │     │ PID 3 (worker)      │
│        entrypoint)  │────▶│                     │
└─────────────────────┘     └─────────────────────┘
        │                           │
        └── PID 1240 on host = PID 1 in container

Network Namespace in Detail:

Network namespaces provide complete network stack isolation:

• Own network interfaces (eth0, lo, etc.)
• Own routing tables
• Own firewall rules (iptables/nftables)
• Own /proc/net

Containers typically get a veth pair—a virtual network cable with one end in the container and one end on the host. The host end connects to a bridge (like docker0), enabling container networking.

While namespaces provide isolation (what a process can see), cgroups (control groups) provide resource control (how much a process can use). Cgroups allow you to:

• Limit resource usage (CPU, memory, I/O bandwidth)
• Prioritize access to resources
• Account for resource usage
• Control processes (freeze, checkpoint, restart)

Cgroup Hierarchy:

Cgroups are organized in a hierarchical filesystem (typically mounted at /sys/fs/cgroup). Each cgroup directory contains files that control and report on the group's resources.

Cgroups v1 vs v2:

Linux has two cgroup versions:

Cgroups v1 (legacy):

• Each controller has a separate hierarchy
• Process can be in different cgroups for different controllers
• More complex, some controllers conflict
• Still common in older systems and some container runtimes

Cgroups v2 (unified):

• Single unified hierarchy
• Process is in exactly one cgroup
• Cleaner interface, better resource distribution
• Now the default in modern distributions

Setting Resource Limits:

Containers need a filesystem—the base operating system libraries, tools, and application code. Container images provide this filesystem in a portable, versioned format. Layered filesystems enable efficient storage and sharing.

Container Images:

An image is a read-only template containing:

• Root filesystem (/, /bin, /lib, /etc, ...)
• Application code and dependencies
• Metadata (entry point, environment variables, exposed ports)

Images are built in layers. Each layer represents a set of filesystem changes (adding files, modifying files, deleting files). Layers are stacked to create the final filesystem view.

The Layering Model:

Union Filesystems:

Layering is implemented using union filesystems (or overlay filesystems). These present multiple directories as a single unified view:

OverlayFS (Linux's built-in union filesystem):

• Lower layers: Read-only image layers (stacked)
• Upper layer: Read-write container layer
• Merged view: Combined view presented to the container

┌─────────────────────────────────────┐
│ Merged View (what container sees)   │
├─────────────────────────────────────┤
│ Upper (R/W) │ Lower 4 │ Lower 3    │
│  ┌──────┐   │ (app)   │ (deps)     │
│  │ logs │   ├─────────┼────────────┤
│  └──────┘   │ Lower 2 │ Lower 1    │
│             │ (python)│ (ubuntu)   │
└─────────────────────────────────────┘

Copy-on-Write (CoW):

When a container modifies a file from a lower layer:

1. The file is copied to the upper (writable) layer
2. The modification is made on the copy
3. The copy in the upper layer "shadows" the original

This is efficient: unchanged files are shared among all containers using the same image. Only modified files consume additional space.

Benefits of Layering:

Container runtimes are the software that actually creates and runs containers. The ecosystem has evolved from monolithic tools to layered, standardized components.

The Container Runtime Stack:

Low-Level Runtimes (OCI Runtimes):

These implement the OCI (Open Container Initiative) runtime specification:

runc — The reference implementation. Created by Docker, now maintained by the containerd project. Actually calls clone() and sets up namespaces/cgroups.

crun — A lightweight alternative written in C. Smaller, faster startup, memory-efficient.

Alternative Runtimes:

gVisor — Google's container runtime with an intercepting kernel (application kernel). Catches system calls and implements them in a user-space kernel, providing stronger isolation without VM overhead.

Kata Containers — Runs each container in a lightweight VM. Combines container UX with VM isolation. Uses a minimal guest kernel and hypervisor.

High-Level Runtimes:

containerd — A graduated CNCF project. Manages the complete container lifecycle: image pull, storage, container execution, networking. Used by Docker and Kubernetes.

CRI-O — Built specifically for Kubernetes. Implements the Container Runtime Interface (CRI) without extra features. Minimal and focused.

Docker Engine — The original container platform. Now uses containerd underneath. Provides the familiar docker CLI, Compose, and Swarm orchestration.

Containers share the host kernel, making security critical. A kernel vulnerability affects all containers. Multiple defense layers are employed to harden container isolation:

Security Mechanisms:

Seccomp Profiles:

Seccomp filters system calls before they execute:

{
  "defaultAction": "SCMP_ACT_ERRNO",
  "syscalls": [
    {
      "names": ["read", "write", "open", "close", ...],
      "action": "SCMP_ACT_ALLOW"
    },
    {
      "names": ["mount", "umount", "reboot", "kexec_load"],
      "action": "SCMP_ACT_ERRNO"
    }
  ]
}

Docker's default seccomp profile blocks ~44 system calls, including those that could facilitate container escape or system damage.

Capability Dropping:

Running one container is simple. Running hundreds across multiple hosts, with networking, storage, scaling, and failure recovery, requires orchestration.

Kubernetes: The Industry Standard

Kubernetes (K8s) has become the de facto standard for container orchestration. It provides:

• Declarative configuration: Define desired state; Kubernetes makes it happen
• Automatic scheduling: Place containers on appropriate nodes
• Self-healing: Restart failed containers, replace unresponsive nodes
• Scaling: Horizontal scaling based on metrics
• Service discovery: DNS-based service discovery and load balancing
• Rolling updates: Zero-downtime deployments
• Secret and config management: Inject configuration without baking into images

Kubernetes Architecture:

┌─────────────────────────────────────────────────────────────┐
│ Control Plane                                               │
│ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐       │
│ │ API Server    │ │ Scheduler     │ │ Controller    │       │
│ │ (kube-apiserver) │               │ │ Manager       │       │
│ └───────────────┘ └───────────────┘ └───────────────┘       │
│ ┌─────────────────────────────────────────────────────┐     │
│ │ etcd (distributed key-value store)                  │     │
│ └─────────────────────────────────────────────────────┘     │
└─────────────────────────────────────────────────────────────┘
                            │
                      (API calls)
                            │
┌─────────────────────────────────────────────────────────────┐
│ Worker Nodes                                                │
│ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │
│ │ Node 1          │ │ Node 2          │ │ Node 3          │ │
│ │ ┌─────────────┐ │ │ ┌─────────────┐ │ │ ┌─────────────┐ │ │
│ │ │ kubelet     │ │ │ │ kubelet     │ │ │ │ kubelet     │ │ │
│ │ ├─────────────┤ │ │ ├─────────────┤ │ │ ├─────────────┤ │ │
│ │ │ container   │ │ │ │ container   │ │ │ │ container   │ │ │
│ │ │ runtime     │ │ │ │ runtime     │ │ │ │ runtime     │ │ │
│ │ ├─────────────┤ │ │ ├─────────────┤ │ │ ├─────────────┤ │ │
│ │ │ [pod][pod]  │ │ │ │ [pod][pod]  │ │ │ │ [pod][pod]  │ │ │
│ │ └─────────────┘ │ │ └─────────────┘ │ │ └─────────────┘ │ │
│ └─────────────────┘ └─────────────────┘ └─────────────────┘ │
└─────────────────────────────────────────────────────────────┘

Core Kubernetes Concepts:

Containers need network connectivity to serve requests and communicate with each other. Container networking leverages Linux network namespaces and virtual networking.

Common Networking Modes:

Bridge Networking in Detail:

┌─────────────────────────────────────────────────────────┐
│ Host Network Namespace                                   │
│                                                          │
│  ┌─────────────────────┐                                │
│  │ Physical Interface  │                                │
│  │ eth0 (192.168.1.10) │◄─────── Internet/LAN          │
│  └─────────────────────┘                                │
│           │                                              │
│           │ NAT (iptables MASQUERADE)                   │
│           │                                              │
│  ┌─────────────────────┐                                │
│  │ Docker Bridge       │                                │
│  │ docker0 (172.17.0.1)│                                │
│  └─────────────────────┘                                │
│       │         │         │                              │
│   ┌───────┐ ┌───────┐ ┌───────┐                        │
│   │veth0  │ │veth1  │ │veth2  │   (veth host ends)     │
└───┴───────┴─┴───────┴─┴───────┴──────────────────────────┘
        │         │         │
┌───────────┐ ┌───────────┐ ┌───────────┐
│Container 1│ │Container 2│ │Container 3│
│eth0:      │ │eth0:      │ │eth0:      │
│172.17.0.2 │ │172.17.0.3 │ │172.17.0.4 │
└───────────┘ └───────────┘ └───────────┘

Container Network Interface (CNI):

CNI is the standard plugin interface for container networking, used by Kubernetes and other orchestrators. CNI plugins handle:

• Creating network namespaces
• Connecting containers to networks (bridge, overlay, etc.)
• Assigning IP addresses (IPAM)
• Setting up routes and firewall rules

Popular CNI plugins: Calico, Flannel, Weave, Cilium (eBPF-based).

Service Mesh (Advanced):

For complex microservices, a service mesh (like Istio, Linkerd) adds a sidecar proxy to each container. The mesh provides:

• Encrypted service-to-service communication (mTLS)
• Observability (distributed tracing, metrics)
• Traffic management (canary deployments, retries)
• Policy enforcement (access control)

We've comprehensively explored OS-level virtualization and containerization. Let's consolidate the essential concepts:

Module Complete:

You've now completed your exploration of virtual machines—from Type 1 hypervisors running directly on hardware, through Type 2 hypervisors on desktop systems, to the hardware extensions that make virtualization efficient, and finally to OS-level virtualization with containers. This comprehensive understanding of virtualization technologies prepares you to make informed decisions about isolation, performance, and architecture in your systems work.