Understanding the Container Stack: Docker, containerd, runc, and Kubernetes Explained

Introduction

The article offers a panoramic view of the container ecosystem, helping readers grasp the relationships and evolution of Docker, containerd, the container runtime, and Kubernetes, along with practical advice for production deployments.

Analogy: Shipbuilding and Shipping

Docker – likened to a full‑featured luxury cruise ship that provides a complete stack (engine, hull, cabins, restaurant, pool) for developers; users simply buy a ticket ( docker run) to enjoy building, distributing, and running containers.

Provides an all‑in‑one experience.

Easy to use but the “hull” is relatively heavy.

containerd – represents the core engine room and hull of the ship; Docker is built on top of it, and you can use this engine directly to create your own fast boats or cargo ships (e.g., Kubernetes).

It is the true power and structure of the vessel.

Enables custom runtimes.

runc – the standard engine inside the engine room, built according to the OCI (Open Container Initiative) specifications.

containerd launches runc to create and run container processes.

Kubernetes – a massive automated shipping‑scheduling system that manages thousands of ships (containers) without requiring each ship to be a luxury cruise; it only cares that the core engine (containerd) and engine room (runc) work efficiently.

Historical Evolution: Why the Stack Was Layered

Initially Docker was a monolithic platform that bundled container lifecycle management, image building, networking, storage, etc. As containers and Kubernetes grew explosively, the community realized:

Kubernetes does not need all Docker features; it only requires reliable, standard image pulling and container execution.

Standardization, not vendor lock‑in, became essential, prompting a modular, standards‑based architecture.

This led to the “splitting Docker” movement, focusing on separation of concerns.

Core Components Explained

1. Docker – Full‑Stack Developer Experience

Position : Complete container platform focused on developer experience.

Components :

Features : Image build, management, networking, storage, logging, etc.

Status : Preferred for development/learning, but production Kubernetes often replaces it with lighter components.

2. containerd – Industrial‑Grade Standard Container Engine

Position : Core, standard, reliable container runtime.

Origin : Extracted from Docker and donated to CNCF.

Functions :

Importance : The essential bridge between Kubernetes and the low‑level runtime (runc).

3. Container Runtime Layer

Low‑Level Runtime (e.g., runc, crun) follows the OCI spec, creates containers from config.json and a rootfs, and runs the container process.

High‑Level Runtime (e.g., containerd, CRI‑O) adds image transfer, logging, monitoring, and other enhancements.

4. Kubernetes and CRI

Kubernetes uses the Container Runtime Interface (CRI), a gRPC API, to interact with runtimes. The typical workflow is:

Kubelet → CRI → containerd/cri‑o → containerd‑shim → runc → container process

The containerd‑shim allows containerd to exit after launching a container, handling STDIO, status reporting, and enabling daemon‑less operation, which supports seamless upgrades and maintenance.

Image and Storage Management

The container stack is usually divided into three layers:

containerd – content store : Stores image layers and configuration files.

containerd – snapshotter : Manages copy‑on‑write filesystems (overlayfs, btrfs).

High‑Level Runtime : Handles image caching and distribution to speed up node startup and optimize storage utilization.

High Availability and Multi‑Runtime Coexistence

containerd‑shim enables a stateless daemon design.

Kubernetes nodes can run multiple runtimes via runtimeClass (e.g., default containerd for regular workloads, Kata Containers for high‑isolation workloads).

Security and Isolation Options

runc : Namespace + cgroup isolation; ~ms startup; suitable for lightweight containers.

gVisor : Syscall interception + userspace kernel; ~10 ms startup; provides a secure sandbox.

Kata : Lightweight VM; ~50‑100 ms startup; high security for enterprise isolation.

Firecracker : MicroVM; ~10 ms startup; ideal for serverless/FaaS scenarios.

Choosing a runtime involves trade‑offs among performance, security, isolation, and startup latency.

Component Summary

Docker : Full‑stack container platform for developers; analogous to a luxury cruise ship.

containerd : Core engine and hull; provides image management, lifecycle control, and standardization.

runc : Standard low‑level runtime; the standard engine that creates container processes.

CRI‑O : Kubernetes‑native runtime; a fast boat specially built for the shipping system.

Kubernetes : Container orchestration system; an automated shipping‑scheduling center.

Practical Recommendations

Local development / learning : Use Docker Desktop for an out‑of‑the‑box experience that quickly illustrates container concepts.

Enterprise Kubernetes production : Prefer containerd for its stability, standard compliance, and low resource footprint.

OpenShift / Red Hat environments : Choose CRI‑O for native integration and lightweight operation.

High‑security isolation : Deploy Kata Containers or gVisor to gain sandbox or lightweight VM isolation.

Serverless / FaaS : Adopt Firecracker for ultra‑fast startup and minimal overhead.

Note: Kubernetes 1.24+ has removed direct support for the Docker Engine (dockershim); Docker Engine is not recommended for production workloads.

Conclusion

The evolution of container technology follows a path from monolithic to modular to standardized:

Docker introduced containers to the masses.

containerd became the core engine, standardizing production usage.

runc provides the OCI‑compliant low‑level implementation.

CRI decouples Kubernetes from specific runtimes.

Advanced runtimes and security sandboxes offer diverse isolation and performance trade‑offs.

This article aims to give you a clear, end‑to‑end understanding of the container core technologies, helping you make informed choices from development to production.