Container Architecture and Runtime Explained

Source: Dev.to

The Core Concept: OS-Level Virtualization

Unlike Virtual Machines (VMs), which virtualize the entire hardware stack and require a full guest OS, Docker uses OS‑level virtualization. This means containers run directly on the host OS’s kernel, providing speed and lightweight operation.

Key OS Technologies Used for Isolation

Containers achieve isolation using two fundamental features built into the Linux kernel (and mirrored/virtualized on Windows/macOS):

Namespaces

Isolate the container’s view of the operating system. Each container gets its own segregated slice of resources, including:

• PID Namespace – containers only see their own processes.
• Net Namespace – containers have their own network interfaces, ports, and routing tables.
• Mount Namespace – containers have their own root filesystem (based on the image layers).

Control Groups (cgroups)

Limit the amount of resources a container can consume. They act as resource controllers, allowing you to cap a container’s access to:

• CPU – limit the percentage of processor time.
• Memory – set hard limits on RAM usage.
• Block I/O – control disk input/output.

In short: Namespaces isolate what a container sees (its view), and cgroups limit what a container uses (its resources).

---

The Engine: Docker Daemon vs. Container Runtime

When you run a command like docker run, several pieces of software work together.

A. The Docker Daemon (dockerd)

The Docker Daemon is the server component that runs in the background. It handles the heavy lifting, including:

• Building images.
• Pulling and pushing images to registries (e.g., Docker Hub).
• Managing storage (volumes) and networking.
• Receiving commands from the CLI and passing them to the appropriate runtime.

B. The Container Runtime

The Container Runtime is the low‑level component that executes the essential tasks of running and managing a container process. It interacts directly with the kernel’s namespaces and cgroups.

High‑Level Runtime (e.g., containerd)

Manages the entire container lifecycle: image transfer, mounting the root filesystem, setting up networking, and logging. The Docker Daemon uses containerd to manage its containers.

Low‑Level Runtime (e.g., runc)

The executable that actually creates and runs the container process. It is the final component that interfaces directly with kernel features (namespaces and cgroups) to enforce isolation. runc is the reference implementation of the OCI Runtime Specification.

The Chain of Command

1. You type docker run ….
2. The Docker CLI sends the command to the Docker Daemon (dockerd).
3. The Docker Daemon prepares the image and passes the request to the high‑level runtime (containerd).
4. containerd extracts the container configuration and hands it off to the low‑level runtime (runc).
5. runc uses namespaces and cgroups to create and run the isolated container process on the host OS kernel.

---

OCI: The Open Container Initiative

OCI provides standardized specifications for the core components of container technology.

• Image Specification – defines what a container image must look like (structure, layers, manifest).
• Runtime Specification – defines how a container runtime (like runc) must be configured and executed.

These standards ensure that images built by one tool (e.g., Docker) can be run by another compliant tool (e.g., Podman or Kubernetes’ Kubelet), promoting portability and preventing vendor lock‑in.

---

What’s Next?

Understanding these low‑level concepts is crucial. Now we know how containers work and what software makes them run. In the next post we will explore the filesystem used in Docker.

Thank you.