Introduction to Linux Containers: A
Technical Overview
Abstract
Linux containers have fundamentally changed how software is developed,
deployed, and managed in production environments. This document provides a
technical overview of container technology, covering the underlying kernel features,
runtime architecture, and practical deployment considerations.
1. Background
Containers provide operating-system-level virtualization by leveraging kernel
features to isolate processes. Unlike traditional virtual machines, containers share
the host kernel and therefore incur significantly less overhead in terms of memory,
CPU, and startup time.
The concept of process isolation is not new. Technologies such as chroot (introduced
in 1979), FreeBSD Jails (2000), and Solaris Zones (2004) all explored forms of OS-
level isolation. Modern Linux containers build upon these ideas using two primary
kernel subsystems: namespaces and cgroups.
2. Kernel Primitives
2.1 Namespaces
Namespaces partition kernel resources so that one set of processes sees one set of
resources while another set of processes sees a different set. Linux supports the
following namespace types:
Namespace Flag Isolates
Mount CLONE_NEWNS Mount points
UTS CLONE_NEWUTS Hostname and domain name
IPC CLONE_NEWIPC System V IPC, POSIX queues
PID CLONE_NEWPID Process IDs
Network CLONE_NEWNET Network devices, stacks, ports
User CLONE_NEWUSER User and group IDs
Cgroup CLONE_NEWCGROUP Cgroup root directory
Each container typically operates within its own set of namespaces, providing the
illusion of a dedicated operating system.
2.2 Control Groups (cgroups)
Cgroups limit and account for resource usage (CPU, memory, disk I/O, network) of
process groups. The cgroup v2 unified hierarchy, now the default on most
distributions, provides:
[Link]: Hard CPU time limits per period
[Link]: Maximum memory usage (with OOM kill on breach)
[Link]: Bandwidth and IOPS limits per block device
[Link]: Maximum number of processes
Example cgroup configuration for a container:
# Limit to 2 CPU cores and 512MB RAM
echo "200000 100000" > /sys/fs/cgroup/container1/[Link]
echo "536870912" > /sys/fs/cgroup/container1/[Link]
3. Container Runtimes
3.1 Low-Level Runtimes
The Open Container Initiative (OCI) defines a standard specification for container
runtimes. runc is the reference implementation, responsible for creating and
running containers according to the OCI runtime spec. It directly interfaces with
kernel namespaces and cgroups.
Other low-level runtimes include:
crun: A faster, C-based alternative to runc
gVisor (runsc): Provides an application kernel that intercepts system calls for
enhanced isolation
Kata Containers: Runs each container in a lightweight VM for hardware-level
isolation
3.2 High-Level Runtimes
High-level runtimes such as containerd and CRI-O manage the container lifecycle
including image pulling, storage, and networking. They delegate actual container
creation to a low-level runtime.
[Container Engine (Docker/Podman)]
|
[High-Level Runtime (containerd/CRI-O)]
|
[Low-Level Runtime (runc/crun)]
|
[Linux Kernel (namespaces + cgroups)]
4. Image Format and Layers
Container images use a layered filesystem. Each layer represents a set of file
changes (additions, modifications, deletions). Layers are content-addressable and
shared across images, reducing storage requirements.
An OCI image manifest contains:
Config: Runtime configuration (environment variables, entrypoint, working
directory)
Layers: Ordered list of filesystem changesets as compressed tar archives
Annotations: Optional metadata
The overlay filesystem (OverlayFS) merges these layers at runtime, presenting a
unified view to the container process while keeping the underlying layers immutable.
5. Networking
Container networking typically uses one of the following models:
1. Bridge mode: Containers connect to a virtual bridge on the host. NAT rules
handle external traffic. This is the default in most runtimes.
2. Host mode: The container shares the host network namespace. No isolation,
but no overhead.
3. Overlay networks: VXLAN or other tunneling protocols enable container-to-
container communication across hosts. Used in orchestrated environments.
4. Macvlan/IPvlan: Containers get their own MAC or IP addresses on the physical
network, appearing as independent hosts.
6. Security Considerations
Containers share the host kernel, which presents a larger attack surface than VM-
based isolation. Key hardening measures include:
Seccomp profiles: Restrict available system calls (default Docker profile blocks
~44 syscalls)
AppArmor/SELinux: Mandatory access control policies
Read-only root filesystems: Prevent runtime modification of container binaries
Rootless containers: Run the container runtime and containers as non-root
User namespace remapping: Map container root to an unprivileged host UID
7. Conclusion
Linux containers provide an efficient, standardized mechanism for application
isolation and deployment. Understanding the underlying kernel primitives is
essential for making informed decisions about security, performance, and
architecture in containerized environments. As the ecosystem matures, innovations
in runtime security and orchestration continue to expand what containers can
reliably support.
References
1. Kerrisk, M. (2013). “Namespaces in operation.” [Link].
2. Open Container Initiative. “Runtime Specification v1.1.”
3. Bhattiprolu, S. et al. (2008). “Virtual Servers and Checkpoint/Restart in
Mainstream Linux.” ACM SIGOPS Operating Systems Review.
4. Manco, F. et al. (2017). “My VM is Lighter (and Safer) than your Container.”
ACM SOSP.