Hypervisors, Containerization, and Docker Internals Study Notes

Core Concepts of Virtualization

• Definition and General Perspective: From a computing perspective, virtualization is the abstraction of physical resources into logical systems. A common everyday experience of virtualization is partitioning a hard disk drive into more than one "virtual" drive.
• Forms of Virtualization:
  • Virtual Memory: Each application sees its own logical memory, which remains independent of the physical memory.
  • Virtual Networks: Each application sees its own logical network, independent of the physical network hardware.
  • Virtual Servers: Each application sees its own logical server, independent of the physical server infrastructure.
  • Virtual Storage: Each application sees its own logical storage, independent of the physical storage devices.
• The Virtualization Foundation: Virtualization removes the $1:1$ relationship between software and physical hardware. It abstracts physical resources into logical systems on a single host.
• Key Drivers for Virtualization:
  • Resource Utilization: Running multiple environments on underutilized physical hardware.
  • Isolation: Preventing application conflicts and ensuring fault boundaries.
  • Reproducibility: Managing the Operating System ($\text{OS}$) and application as a single, portable unit.
• Hardware and Logical System Example:
  • Physical Hardware: CPU: $8$ cores; RAM: $128\,GB$; Storage: $2\,TB$ NVMe; Network: $10\,GbE$.
  • Logical System 1: vCPU: $2$; vRAM: $32\,GB$; vStorage: $500\,GB$; App: Web Server; OS: Linux.
  • Logical System 2: vCPU: $4$; vRAM: $64\,GB$; vStorage: $1\,TB$; App: Database; OS: Linux.
  • Logical System 3: vCPU: $2$; vRAM: $16\,GB$; vStorage: $250\,GB$; App: Development; OS: Windows.

The Virtual Machine Monitor (Hypervisor)

• Definition: The Hypervisor is a dedicated software layer responsible for providing the virtualization interface. It sits between the hardware pool and the virtual environments.
• Core Responsibilities:
  • Carving: It slices physical resources (CPU, RAM, Disk) into discrete, manageable fractions.
  • Presentation: It presents these carved resources to a Guest Operating System as if they were dedicated, bare-metal hardware.
  • Translation: It intercepts and translates hardware calls from the virtual environments to the physical host.
• Type 1 Architecture: Bare Metal:
  • The hypervisor operates natively on the hardware.
  • There is no intermediary host operating system.
  • It possesses direct, low-level control over the physical CPU and memory.
  • Benefits include optimized translation speed and maximized resource allocation for virtual machines.
• Type 2 Architecture: Hosted:
  • The hypervisor runs as a standard software application within an existing Host Operating System.
  • It is easier to deploy on standard consumer hardware.
  • The Drawback: Every hardware request from the virtual machine must pass through two distinct operating system kernels (the Guest OS kernel and the Host OS kernel).

The Limitations and Overhead of Virtual Machines

• Traditional vs. Virtualized Stacks:
  • Traditional: Software and hardware are tightly coupled; a single OS per machine leads to underutilized resources.
  • Virtualized: Hypervisors break hardware dependency by dividing one physical server into multiple Virtual Machines ($\text{VMs}$), providing strong fault and security isolation.
• The Heavyweight VM Problem:
  • The Bloat: Every single VM requires a full, redundant copy of an operating system, background services, and hardware drivers. For example, a $5\,MB$ app might require a Guest OS of $2\,GB+$ to run.
  • The Cost: Running a tiny web app requires gigabytes of RAM and CPU cycles just to keep the redundant Guest OS alive.
  • The Bottleneck: Boot times are measured in minutes, not seconds, making rapid scaling nearly impossible.
• The Boot Sequence Gap:
  • A VM must undergo a sluggish boot sequence: Boot Virtual BIOS $\rightarrow$ Initialize Virtual Hardware $\rightarrow$ Load Guest OS Kernel $\rightarrow$ Start System Services $\rightarrow$ Launch App.
  • This takes minutes compared to the seconds required for the actual desired application execution.
• Compounding Resource Waste: Deploying $500$ Virtual Machines on a single host means loading, booting, and powering $500$ independent, nearly identical OS kernels. System RAM and CPU cycles are consumed by background OS maintenance rather than actual application computation.

Containerization: OS-Level Virtualization

• Core Difference: A container is not a Virtual Machine. Containers virtualize the Operating System, not the hardware. They run as isolated processes in userspace, sharing a single host kernel.
• The Paradigm Shift: Containerization removes the hypervisor and redundant Guest OS entirely.
• Comparison Table: VM vs. Docker Container:

• Conceptual Model: "A Process Under House Arrest":
  • The Reality: A container is a standard process (or group of processes) running on the host OS.
  • The Illusion: The Linux kernel applies specific rules that make the process think it is entirely alone on a separate machine.
  • Boundaries: Containers leverage native kernel capabilities to put a process under house arrest rather than inventing new isolation methods.

Docker Internals: The Three Pillars of Isolation

• The Shield: Namespaces: Determines what a process can see. It creates the isolation environment.
  • PID (Process ID): The ultimate illusion. The process thinks it is PID $1$. It cannot see or kill host processes.
  • MNT (Mount): Provides an isolated filesystem. The process cannot see the host's $/etc$ or $/home$ directories.
  • NET (Network): Assigns a private virtual network stack, unique IP address, and isolated port range.
  • UTS (Hostname): Grants a distinct, isolated hostname.
• The Fence: Control Groups (Cgroups): Determines what a process can use. It creates resource governance.
  • The Noisy Neighbor Problem: Without governance, one container could crash the host by consuming all system resources.
  • Resource Limits: Cgroups rigidly enforce CPU shares, memory limits, and I/O priority. For example, Container A can be limited to never exceed $512\,MB$ RAM and $10\%$ CPU, regardless of demand.
• The Canvas: UnionFS (Union File System): Determines how a process stores data. It creates layer efficiency.
  • Mechanism: Docker images use Overlay FS, which are built in reusable layers rather than monolithic files.
  • The Shared Foundation: A base layer (e.g., Ubuntu root filesystem) is stored on the host OS exactly once.
  • The Multiplier Effect: $100$ booted containers share that single read-only base layer, reducing disk footprint and enabling sub-second startups.
  • The Thin Writable Layer: Each container gets its own thin writable layer on top of shared read-only dependency/app layers.

Docker Architecture and Orchestration

• Synthesis Insight: Docker did not invent isolation; it democratized pre-existing Linux kernel features through an elegant UI and standardized how software is shipped.
• The Equation: $\text{Namespaces (Isolation)} + \text{Cgroups (Control)} = \text{Container Behavior}$.
• Components of the Docker Engine:
  • Docker Client: The command line interface (CLI) where users type commands (e.g., docker run).
  • Docker Daemon: The background service on the Host System that translates user commands into instructions for the Linux Kernel.
  • Docker Registry (Docker Hub): A central repository for storing and downloading images.
• Execution Translation Process:
  1. User Types: docker run nginx in the terminal.
  2. Daemon Translates: Docker Engine pulls image layers and calculates requirements.
  3. Kernel Allocates: Linux Kernel assigns new Namespaces (PID, MNT) and wraps the process in Cgroups (Memory, CPU).
  4. Result: Isolated container is born in milliseconds.

Dockerfile and Deployment Pipeline

• Anatomy of a Dockerfile (Example):
  • FROM gcc:4.9: Pulls the read-only base layer containing the compiler.
  • RUN mkdir -p /app: Modifies the intermediate layer.
  • COPY . /app: Injects local code directly into the container's isolated MNT namespace.
  • RUN g++ helloaos.cpp -o hello: Compiles the binary inside the isolated environment.
  • CMD ["./hello"]: Defines the process that becomes PID $1$ when the container boots.
• The Standardized Deployment Pipeline:
  • Machine (Development) $\rightarrow$ Push Code to Git/Build Server $\rightarrow$ Push Image to Docker Registry $\rightarrow$ Deploy to Production machine.
  • The Result: Because the container packages code, runtime, and system tools, it eliminates the "It works on my machine" problem.
  • The Ultimate Goal: Packaging an application in a mathematically identical environment that runs flawlessly, in seconds, on any machine on Earth.