Understanding Low‑Level vs High‑Level Container Runtimes and CRI in Kubernetes

Although the container ecosystem seemed to fade after the rise of CoreOS and Docker, the emergence of Rust and projects such as Firecracker and youki has revived interest, making container runtime history and technology a common interview topic for cloud‑native practitioners.

01 Requirement Overview

Note: “Container runtime” refers to the container runtime.

In the Docker era the term “container runtime” was clearly defined as software that runs and manages containers. As Docker’s scope expanded and orchestration tools appeared, the definition became blurred.

When you run a Docker container, the typical steps are:

Download the image.

Unpack the image into a bundle (flatten layers into a single filesystem).

Run the container.

The original specification only defined the part that runs the container as the runtime, but users usually expect all three steps to be supported, making the definition confusing.

Common container runtime projects include runc, runv, lxc, lmctfy, Docker (containerd), rkt, cri‑o, etc. Some, like containerd and cri‑o, implement higher‑level functions on top of runc.

Container runtimes can be divided into low‑level and high‑level categories.

02 Low‑Level Container Runtime

Low‑level runtimes perform only basic container execution tasks and follow the OCI specification. They accept a rootfs and a config.json, but provide no image management, networking, or storage implementation.

Only understand rootfs and config.json; no other image capabilities.

No network implementation.

No persistent storage.

Not cross‑platform, etc.

Low‑Level Runtime Demo

The demo uses root privileges with Linux commands

cgcreate

,

cgset

,

cgexec

,

chroot

and

unshare

to create a simple container.

<code>$ CID=$(docker create busybox)</code>
<code>$ ROOTFS=$(mktemp -d)</code>
<code>$ docker export $CID | tar -xf - -C $ROOTFS</code>

Generate a UUID and set memory and CPU limits (e.g., 100 MB memory).

<code>$ UUID=$(uuidgen)</code>
<code>$ cgcreate -g cpu,memory:$UUID</code>
<code>$ cgset -r memory.limit_in_bytes=100000000 $UUID</code>
<code>$ cgset -r cpu.shares=512 $UUID</code>

Set CPU quota to restrict the container to two CPU cores.

<code>$ cgset -r cpu.cfs_period_us=1000000 $UUID</code>
<code>$ cgset -r cpu.cfs_quota_us=2000000 $UUID</code>

Execute a command inside the container.

<code>$ cgexec -g cpu,memory:$UUID \
    unshare -uinpUrf --mount-proc \
    sh -c "/bin/hostname $UUID && chroot $ROOTFS /bin/sh"</code>

Finally, remove the cgroup and temporary directory.

Representative Low‑Level Runtimes

runC – the most widely used OCI runtime, originally part of Docker and later extracted as a standalone tool.

rkt (deprecated) – provides both low‑ and high‑level functionality, similar to Docker.

runV – a hypervisor‑based runtime that has been superseded by Kata Containers.

youki – an OCI runtime implemented in Rust, analogous to runC.

03 High‑Level Container Runtime

High‑level runtimes handle image transfer and management, unpack images, and delegate actual container execution to a low‑level runtime. They usually expose a daemon and an API for remote control.

They also manage networking namespaces and allow containers to join other containers’ network namespaces.

High‑Level Runtime Examples

Docker – the earliest open‑source container runtime, originally a monolithic daemon (dockerd) that combined image building, management, and container execution. Modern Docker splits these responsibilities into

containerd

(image management) and

runc

(low‑level execution).

containerd – extracted from Docker, it downloads, stores, and runs images, creating an OCI bundle and invoking

runc

. It provides a CLI (

ctr

,

nerdctl

) and an API.

Typical

containerd

commands:

<code>$ sudo ctr images pull docker.io/library/redis:latest</code>

<code>$ sudo ctr images list</code>

<code>$ sudo ctr container create docker.io/library/redis:latest redis</code>

<code>$ sudo ctr container list</code>

<code>$ sudo ctr container delete redis</code>

rkt (deprecated) – also offers low‑ and high‑level features similar to Docker.

04 Kubernetes CRI

CRI was introduced in Kubernetes 1.5 as a bridge between kubelet and container runtimes. A runtime that implements CRI must be a high‑level runtime because it manages images, pods, and containers.

CRI Specification

CRI defines a gRPC API with services such as

ImageService.PullImage

,

RuntimeService.RunPodSandbox

,

RuntimeService.CreateContainer

,

RuntimeService.StartContainer

, and

RuntimeService.StopContainer

.

<code>ImageService.PullImage({image: "image1"})</code>
<code>ImageService.PullImage({image: "image2"})</code>
<code>podID = RuntimeService.RunPodSandbox({name: "mypod"})</code>
<code>id1 = RuntimeService.CreateContainer({pod: podID, name: "container1", image: "image1"})</code>
<code>id2 = RuntimeService.CreateContainer({pod: podID, name: "container2", image: "image2"})</code>
<code>RuntimeService.StartContainer({id: id1})</code>
<code>RuntimeService.StartContainer({id: id2})</code>

The

crictl

tool can be used to interact with a CRI runtime for debugging and testing.

<code>cat <<EOF | sudo tee /etc/crictl.yaml
runtime-endpoint: unix:///run/containerd/containerd.sock
EOF</code>

<code>crictl --runtime-endpoint unix:///run/containerd/containerd.sock …</code>

Runtimes Supporting CRI

containerd – the most popular CRI runtime, implements CRI as a plugin and supports multiple low‑level runtimes via runtime handlers (e.g., gVisor, Kata Containers) configured through Kubernetes RuntimeClass.

Docker (docker‑shim) – the first CRI shim; now deprecated as Docker’s functionality has moved to containerd.

CRI‑O – a lightweight CRI runtime that implements OCI, providing image management, container process management, logging, and resource isolation.

The author acknowledges possible omissions and invites feedback from readers and experts.