6.1 Container Fundamentals, Runtimes & Registries

6.1 Container Fundamentals, Runtimes & Registries

Quick Answer: Containers are lightweight, isolated user-space processes running directly on the host operating system kernel using Linux kernel namespaces for isolation and control groups (cgroups) for resource constraints. Unlike Virtual Machines, containers do not require hypervisors or dedicated guest operating systems. The Open Container Initiative (OCI) standardizes container images, runtimes, and registries. Kubernetes manages containers via the Container Runtime Interface (CRI), utilizing high-level runtimes like containerd and CRI-O which delegate process execution to low-level runtimes like runc.

Modern cloud-native software architecture relies on container virtualization as its foundational building block. To master application delivery in Kubernetes, candidates must understand how containers differ from traditional virtual machines, how the Linux kernel enforces process isolation, how standards organizations like the Open Container Initiative (OCI) normalize image formats, and how secure container build practices mitigate enterprise software vulnerabilities.

---

Containers vs. Virtual Machines

Before containerization became widespread, hardware virtualization via hypervisors was the primary mechanism for isolating enterprise application workloads. Understanding the structural differences between Virtual Machines (VMs) and containers is essential for evaluating performance, resource efficiency, and security isolation boundaries.

Virtual Machine Architecture

Virtual Machines rely on a hypervisor (Type 1 bare-metal hypervisors like VMware ESXi or KVM, or Type 2 hosted hypervisors like VirtualBox). The hypervisor abstracts physical hardware resources (CPU, RAM, storage, network controllers) to create virtualized hardware environments. Each VM runs a complete, independent guest operating system containing its own kernel, system binaries, device drivers, and application stack. While this architecture provides hardware-level security isolation, it incurs heavy resource overhead, large storage footprints (gigabytes per VM), and slow startup times ranging from tens of seconds to several minutes.

Container Architecture

Containers operate via OS-level virtualization. Instead of virtualizing underlying hardware, containers share the host operating system kernel. Every container runs as an isolated user-space process directly on the host OS. Because containers omit guest kernels and virtual device drivers, they start almost instantaneously (milliseconds to seconds), consume minimal memory, and pack significantly higher workload density onto physical hardware.

---

Linux Kernel Isolation Mechanisms

Containers achieve process isolation without hypervisors by combining primitive features built directly into the Linux kernel: Namespaces, Control Groups (cgroups), and security modules.

Linux Namespaces (Process Isolation)

Namespaces provide process-level isolation by wrapping global system resources into virtualized instances. A process executing inside a container namespace sees only its own isolated slice of system resources:

• PID Namespace: Isolates the process ID space. The primary container application receives PID 1 inside its namespace, while possessing a standard non-PID 1 process ID on the host OS.
• NET Namespace: Isolates network interfaces, IP addresses, routing tables, and port binding spaces.
• MNT (Mount) Namespace: Isolates filesystem mount points, providing the container with its own root filesystem (/).
• IPC Namespace: Isolates Inter-Process Communication resources, such as System V IPC objects and POSIX message queues.
• UTS Namespace: Isolates hostnames and NIS domain names.
• USER Namespace: Maps container-internal user and group IDs to different user IDs on the host system, allowing a container root user (UID 0) to map to an unprivileged user on the host.
• CGROUP Namespace: Hides control group paths from processes inside the container.

Control Groups (cgroups v1 / cgroups v2)

While namespaces control what a process can see, cgroups govern how much a process can consume. Developed originally by Google engineers and merged into the Linux kernel, cgroups enforce resource allocation boundaries and resource monitoring:

• CPU Allocation: Specifies CPU share limits, quota periods, and CPU core pinning (cpuset).
• Memory Limits: Enforces hard memory caps. Exceeding memory limits triggers the Linux kernel Out-Of-Memory (OOM) killer to terminate the container.
• Block I/O (blkio): Throttles read and write access rates to physical disks.
• Network Traffic: Controls network traffic prioritization and egress shaping.

Security Modules (Seccomp, AppArmor, SELinux)

To restrict system call privilege escalation, container runtimes apply Seccomp (Secure Computing Mode) profiles to filter forbidden Linux system calls (e.g., blocking reboot or ptrace). Mandatory Access Control (MAC) frameworks like AppArmor and SELinux further restrict container process file access and capability vectors.

---

The Open Container Initiative (OCI) & Container Runtimes

To prevent vendor lock-in and fragmentation after Docker's early popularity, the industry established the Open Container Initiative (OCI) in June 2015 under the Linux Foundation. (The CNCF was founded separately later the same year; it is a sibling foundation under the same umbrella, not the OCI's parent.) The OCI publishes three core open specifications:

1. OCI Image Specification (image-spec): Defines the structure of container images, including filesystem layer tarballs, image manifests, layer diff hashes, and runtime configuration JSON metadata.
2. OCI Runtime Specification (runtime-spec): Specifies the lifecycle events (create, start, pause, kill, delete) and configuration format required to execute a container bundle on disk.
3. OCI Distribution Specification (distribution-spec): Defines a standardized HTTP REST API for pushing, pulling, and authenticating container images across registries.

┌─────────────────────────────────────────────────────────────────────────────┐
│                    Kubernetes Container Runtime Stack                       │
├─────────────────────────────────────────────────────────────────────────────┤
│                           kubelet (Node Agent)                              │
└──────────────────────────────────────┬──────────────────────────────────────┘
                                       │ gRPC (Container Runtime Interface - CRI)
┌──────────────────────────────────────▼──────────────────────────────────────┐
│  High-Level Container Runtime (containerd / CRI-O)                         │
│  • Image Pulling & Storage Layer Management                                │
│  • CNI Network Interface Plumbing                                           │
│  • Container Lifecycle & Execution Supervision                              │
└──────────────────────────────────────┬──────────────────────────────────────┘
                                       │ OCI Runtime Spec (JSON + Rootfs)
┌──────────────────────────────────────▼──────────────────────────────────────┐
│  Low-Level Container Runtime (runc / kata-containers / gVisor)             │
│  • Configures cgroups & namespaces directly via Linux Kernel syscalls       │
│  • Spawns application process and exits/supervises                          │
└─────────────────────────────────────────────────────────────────────────────┘

Container Runtime Interface (CRI)

Kubernetes decouples node agents (kubelet) from specific runtime implementations using the Container Runtime Interface (CRI). The CRI is a gRPC protocol defining RPC methods for managing image repositories (ImageService) and container lifecycles (RuntimeService). The removal of legacy dockershim in Kubernetes v1.24 solidified CRI as the mandatory abstraction layer.

High-Level vs. Low-Level Runtimes

Container runtimes are split into two distinct tiers:

• High-Level Runtimes (containerd, CRI-O): Manage image pulling from registries, layer unpacking, snapshot storage, network interface setup via CNI, and process supervision. Both containerd (a CNCF Graduated project originated by Docker) and CRI-O (a lightweight CNCF Graduated runtime built specifically for Kubernetes) implement the CRI gRPC interface.
• Low-Level Runtimes (runc, Kata Containers, gVisor): Focus exclusively on interfacing with the Linux kernel to create namespaces, cgroups, and execute container binaries defined by the OCI runtime-spec. runc is the standard reference implementation written in Go. For multi-tenant environments requiring heightened security, sandboxed runtimes like Kata Containers (lightweight VMs) or gVisor (application kernel intercepting syscalls) replace runc.

---

Dockerfile Best Practices & Security Hardening

Container images serve as the deployment artifacts in cloud-native pipelines. Constructing secure, efficient, and minimal container images requires following established Dockerfile engineering practices:

1. Multi-Stage Builds: Separate the build-time compilation environment from the runtime environment. Multi-stage builds utilize multiple FROM statements in a single Dockerfile, allowing heavy build dependencies (compilers, SDKs, build caches) to be discarded before generating the final production image.
2. Minimal Base Images: Avoid general-purpose OS images (like full Ubuntu or Debian) in production. Use minimal base images such as Alpine Linux (lightweight musl libc distribution) or Google Distroless images (containing only your application binary and runtime dependencies, without shells or package managers).
3. Non-Root Execution: By default, containers execute as root (UID 0) unless explicitly configured otherwise. Production Dockerfiles should create an unprivileged system user and group and declare the USER instruction (USER 10001:10001).
4. Layer Optimization & Caching: Order Dockerfile instructions from least frequently changed to most frequently changed to leverage layer caching. Combine related RUN commands into single lines using && to minimize layer creation and clear transient package manager caches within the same layer (e.g., apt-get clean && rm -rf /var/lib/apt/lists/*).

Production Multi-Stage Dockerfile Example

# Stage 1: Build Environment
FROM golang:1.22-alpine AS builder
WORKDIR /app
# Copy dependency manifests first for layer caching
COPY go.mod go.sum ./
RUN go mod download
# Copy source code and build statically linked binary
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-w -s" -o server .

# Stage 2: Minimal Production Runtime
FROM gcr.io/distroless/static-debian12:nonroot
WORKDIR /app
# Copy binary from builder stage
COPY --from=builder /app/server /app/server
# Expose application port and set unprivileged user execution
EXPOSE 8080
USER nonroot:nonroot
ENTRYPOINT ["/app/server"]

---

OCI Registries & Image Vulnerability Scanning

Container images are stored, versioned, and distributed through OCI Registries. Registries manage image repositories containing image tags and cryptographic digests (e.g., sha256:abcd...).

Enterprise Registries

While public registries like Docker Hub provide access to open-source software, enterprise production workloads rely on private, secure OCI registries:

• Harbor: A CNCF Graduated open-source enterprise registry providing role-based access control (RBAC), image replication, vulnerability scanning integration, and content trust signing via Cosign/Notary.
• Quay: Red Hat's enterprise-grade container registry supporting automated security scanning and geo-replication.
• Cloud Provider Registries: Amazon ECR, Google Artifact Registry, and Azure Container Registry.

Vulnerability Scanning (Trivy)

Securing application delivery requires scanning container images for Known Vulnerabilities and Exposures (CVEs) before deployment. Trivy (by Aqua Security) is a widely adopted open-source vulnerability scanner for container images and OCI artifacts. Integrating Trivy into CI/CD pipelines allows teams to fail automated builds if critical CVEs or misconfigurations are detected in base image OS packages or language dependencies.