So many layers of abstraction. But tl;dr:
K8s / docker - containerd / cri-o - runtime
Tools end users use to run containers
k8s is an orchestrator for scheduling/running containers across multiples nodes (machines).
Supports different runtimes
declared in RuntimeClass in node.k8s.io/v1beta1.
Runtimes can be selected through runtimeClassName in a PodSpec.
The interface for pluggable runtimes to support is [CRI][#cri-container-runtime-interface].
docker is a engine/daemon/cli for running containers on a single machine.
Supports different runtimes declared in runtimes in daemon.json.
Runtimes can be selected through --runtime=x or default-runtime in daemon.json.
The interface for pluggable runtimes to support is [OCI][oci-open-container-initiative-runtime-specification].
k8s standard for high level runtimes. Not sure of any practical difference between the 2 main implementations.
Broken out of docker, containerd is the high level daemon responsible for the container lifecycle.
CNCF Graduated, supports low level OCI runtimes through a shim
Developed by RedHat,
cri-o / crio is a lightweight alternative
to running containers.
CNCF Incubating, supports OCI runtimes.
docker through dockershim, adds extra layer between k8s and containerd, doesn't allow for different runtime classes. Likely to be deprecated in future?
frakti is a runtime for VMs.
OCI Runtime Spec is the standard for low level container runtimes, detailing how to run a "filesystem bundle". Not to be confusted with OCI Image Spec.
runc is the default/reference implementation for low level container runtimes.
gVisor is a process kernel by Google in Go.
Use as a standalone low level runtime as runsc or with containerd containerd-shim-runsc-v1
MicroVM by Amazon in Rust.
Use with Kata kata-fc or with containerd [firecracker-containderd][firecracker-containderd].
Lightweight VMs?
Use as a standalone low level runtime as kata-runtime
or with containerd io.containerd.kata.v2