Understanding Kubernetes Runtime: From Docker to Kata and Beyond

Runtime Landscape Overview

Runtime development has accelerated, offering many options such as Docker, rkt, containerd, cri‑o, Kata, gVisor, and more. The article explains what a runtime is, its architecture, and the relationships among OCI, CRI, and commonly misused terminology.

Typical Docker Runtime Flow

When Kubelet creates a container, it follows these steps:

Kubelet calls the CRI interface (gRPC) to dockershim, which acts as a server within Kubelet.

Dockershim translates the request for the Docker daemon.

Docker daemon forwards the request to containerd (since Docker 1.12).

containerd spawns a containerd-shim process to act as the container’s parent, preserving state across containerd restarts.

The shim uses the OCI‑specified runc tool to set up namespaces, cgroups, and the root filesystem.

After runc exits, the shim becomes the container’s parent, handling lifecycle events and cleanup.

This layered design explains why Docker and dockershim appear as separate components.

Container History

Early Kubernetes used a simple Docker‑daemon approach with the libcontainer library. Political and technical pressures led to the creation of the OCI standard, the donation of libcontainer as runc, and the emergence of alternative runtimes like rkt. To avoid endless compatibility bugs, Kubernetes introduced the CRI in v1.5, allowing any implementation that satisfies the interface.

OCI and CRI Definitions

OCI defines two specifications:

ImageSpec : describes the compressed image layout.

RuntimeSpec : defines required container lifecycle commands (create, start, stop, delete).

CRI is a set of gRPC interfaces for container operations, image management, and PodSandbox handling.

Runtime Ecosystem

Projects compatible with OCI include runc , Kata (and its predecessors), and gVisor . CRI‑compatible projects include Docker (via dockershim), containerd (with CRI‑containerd), and CRI‑O .

Three‑Layer Abstraction

1 Orchestration API -> Container API -> Kernel API

Kubernetes implements the Orchestration API, CRI provides the Container API, and OCI implements the Kernel API.

containerd and CRI‑O

containerd originally used a separate CRI‑containerd process for CRI adaptation; later versions integrated the logic as a plugin. CRI‑O offers a lightweight, Kubernetes‑specific runtime that directly implements both OCI and CRI, using conmon as its shim equivalent.

Strong‑Isolation Containers

To achieve true multi‑tenant isolation, projects like Kata , gVisor , and firecracker run containers inside lightweight VMs or user‑mode kernels. Kata uses OCI images, gVisor employs a user‑space “Sentry” process, and firecracker provides a minimal microVM built in Rust.

Security Containers and Serverless

Strong isolation is essential for serverless platforms, which require fast sandbox creation and minimal resource overhead. MicroVMs such as firecracker offer the necessary isolation while keeping startup latency low, making them suitable for FaaS workloads.

Conclusion

The article provides a comprehensive view of Kubernetes runtimes, their historical evolution, standards, and trade‑offs, helping readers choose appropriate runtimes and understand the design logic behind the ecosystem.