Partially systematized. Eventually, will include some commentary.
runc - "CLI tool for spawning and running containers according to the OCI specification." The reference implementation of the holly OCI Runtime Specification. Written in Go.
crun - "A fast and lightweight fully featured OCI runtime and C library for running containers" - much like runc but written in C and with a possibility to use as a library.
youki - "A container runtime written in Rust." Same as above, but in Rust.
runj - "An experimental, proof-of-concept OCI-compatible runtime for FreeBSD jails."
runv - "Hypervisor-based Runtime for OCI."
sysbox - "An open-source, next-generation "runc" that empowers rootless containers to run workloads such as Systemd, Docker, Kubernetes, just like VMs." Started as an independent project but was acquired by Docker Inc. in May 2022.
gVisor - "Application Kernel for Containers." gVisor is an application kernel (User-mode Linux), written in Go, that implements a substantial portion of the Linux system surface. It includes an Open Container Initiative (OCI) runtime called runsc that provides an isolation boundary between the application and the host kernel. The runsc runtime integrates with Docker and Kubernetes, making it simple to run sandboxed containers.
Quark - "A secure container runtime with CRI/OCI interface." Quark provides VM-level workload isolation and security with its own hypervisor (QVisor) and a guest kernel (QKernel) - yet another User-mode Linux implementation?
firecracker - "Secure and fast microVMs for serverless computing."
Kata Containers - "An open source project and community working to build a standard implementation of lightweight Virtual Machines (VMs) that feel and perform like containers, but provide the workload isolation and security advantages of VMs."
libkrun - "A dynamic library providing Virtualization-based process isolation capabilities." Can be used for adding VM-isolation capabilities to an OCI runtime like runc, crun, etc.
bubblewrap - "Unprivileged sandboxing tool."
systemd-nspawn - "Like the chroot command, but it is a chroot on steroids." May be used to run a command or OS in a light-weight namespace container.
NsJail - "A light-weight process isolation tool, making use of Linux namespaces and seccomp-bpf syscall filters (with help of the kafel bpf language)."
Kuasar - "An efficient container runtime that provides cloud-native, all-scenario multiple sandbox container solutions." Kuasar is a facade runtime that turns other runtimes into sandboxers implementing the containerd Sandbox API. Currently supported sandboxers: MicroVM (Cloud Hypervisor, StratoVirt and QEMU), App Kernel (gVisor and Quark), and Wasm (WasmEdge).
urunc - "A simple container runtime that aspires to become runc for unikernels."
urunc leverages the OCI container semantics and offers compatibility with the Kubernetes Container Runtime Interface (CRI) for unikernels. It uses a hypervisor to launch unikernels provided by OCI-compatible images, allowing packaging, delivering, and managing unikernel-based software using traditional Cloud Native practices.
More about the design and concept in this KubeCon EU 2024 talk.
Contrast - "Deploy and manage confidential containers on Kubernetes." Confidential Containers are Kubernetes Pods that are executed inside specialized microVMs, which provide strong hardware-based isolation from the surrounding environment. Contrast works with unmodified OCI containers in a lift-and-shift approach. The project is based on Kata Containers and Confidential Containers, and it currently targets the CoCo preview on AKS.
containerd - "An open and reliable container runtime."
firecracker-containerd - "enables containerd to manage containers as Firecracker microVMs."
Flintlock - "Lock, Stock, and Two Smoking MicroVMs. Create and manage the lifecycle of MicroVMs backed by containerd." Create and manage the lifecycle of MicroVMs, backed by containerd.
Vorteil - "turn your applications and containers into micro virtual machines."
cri-o - "Open Container Initiative-based implementation of Kubernetes Container Runtime Interface (CRI)."
virtlet - "Kubernetes CRI implementation for running VM workloads."
LXC - "Linux Containers." An alternative (i.e., non-OCI) implementation of containers using Linux OS-level virtualization primitives (namespaces, cgroups, etc). Daemonless, can work as a library or as a CLI tool. Back in 2013, Docker started as a UX layer on top of LXC but eventually moved to its own implementation (known as libcontainer & runc today). The key design difference between Docker and LXC is that the former focuses on single-purpose containers (i.e., one container - one application), while the latter tries to be a seamless replacement for traditional (potentially multi-tenant) Linux servers (VM or bare metal, doesn't matter). Read this alternative story of containers on LWN.net for more.
rkt - [discontinued] "rkt is a pod-native container engine for Linux. It is composable, secure, and built on standards."
conman - a toy container manager written for educational purposes. Read more about the conman project on iximiuz.com.
Moby - "A collaborative project for the container ecosystem to assemble container-based systems." Docker lives somewhere here.
compose - "Define and run multi-container applications with Docker."
Podman - "A tool for managing OCI containers and pods." Daemonless drop-in replacement for Docker (not quite).
LXD - "Powerful system container and virtual machine manager." Formerly a daughter project of LCX, it is now a Canonical project. Like the Docker daemon, LXD is a daemon that (in particular) provides HTTP API to manage containers powered by LXC. LXD comes with a CLI client called lxc (not to be confused with LXC's own CLI clients, though).
Incus - also a "Powerful system container and virtual machine manager." A community-led fork of Canonical's LXD (see above). Incus "is roughly equivalent to LXD but with a number of breaking changes on top of the obvious rename." While Incus promises to maintain backward compatibility (with itself) in its future versions, the early days of the fork are used as an opportunity to remove a lot of unused or problematic features of LXD.
Focker - "A FreeBSD image/jail orchestration tool in the vein of Docker."
A Docker-like tool written in Python and using FreeBSD jails instead of Linux namespaces & co.
footloose - "Container Machines - Containers that look like Virtual Machines."
Regular containers but with systemd as PID 1 and an SSH daemon inside. Such "machines" behave very much like a VM, it's even possible to run dockerd in them.
Rootbox - "An extremely simple and fast container engine for Linux and WSL, written in Python."
A piece of software that sits in between a low-level container runtime and a higher-level container runtime.
conmon - "An OCI container runtime monitor."
conmon-rs - conmon, but in Rust.
containerd-runtime-shim - "A first class shim API [and a few implementations] for runtime authors to integrate with containerd."
shimmy - a toy container runtime shim written for educational purposes. Part of the conman project.
cdebug - "a swiss army knife of container debugging."
The cdebug exec command is a crossbreeding of docker exec and kubectl debug commands. You point the tool at a running container, say what toolkit image to use, and it starts a debugging "sidecar" container that feels like a regular docker exec session (i.e., shares most of the target container's namespaces and has the same rootfs).
The cdebug port-forward command is another crossbreeding - this time it's kubectl port-forward and ssh -L|-R. With cdebug port-forward -L you can forward traffic destined to a host's port to an arbitrary container port even if it wasn't published or the target container is listening on localhost. With cdebug port-forward -R (coming soon) you can expose any endpoints accessible from your host back to the container' or Kubernetes network.
debug-ctr - "Commandline tool for interactive container troubleshooting."
A debugger that creates a new container out of the original container with the toolkit mounted in a volume.
docker-debug - "use new container attach on already container go on debug."
Start a new container with an image of choice (nicolaka/netshoot by default) that shares (some of) the target container's namesapces. Much like cdebug exec but with no chroot magic and supports only Docker as a container runtime.
docker-opener - "Shell-in to any docker container easily."
A multi-purpose tool that in particular can run a shell session into your container (and if there is no shell inside, it'll bring its own busybox).
cntr - "A container debugging tool based on FUSE."
"A replacement for docker exec that brings all your developers tools with you" by mounting the file system from one container (or the host) into the target container and creating a nested container with the help of a FUSE filesystem. Supports a huge range of runtimes (docker, podman, LXC/LXD, rkt, systemd-nspawn, containerd) because it operates directly on the OS level.
kdiag - "Diagnostics and Debug Tooling" for Kubernetes workloads.
A kubectl plugin to get shell access to scratch containers, stream logs from multiple pods simultaneously, and do reverse port forwarding to Kubernetes clusters.
containerdbg - "Automate container debugging tasks."
An "all-in-one" (more like "several-in-one" at the moment) CLI to help debug Kubernetes workloads with common issues that arise when moving legacy applications to containers. Can detect missing files (by tracking open file requests via Cilium's eBPF library), fs race conditions (when rename and move are assumed atomic), and failed network connections and static IP usage (via miekg's DNS tracing library). Written in C.
amicontained - "Container introspection tool. Find out what container runtime is being used as well as features available."
ig - "Collection of eBPF gadgets for containers."
ig provides a set of eBPF gadgets that can be used to debug workloads running in containers. It supports multiple runtimes such as Docker, containerd, CRI-O, and Podman. The gadgets are classified into different categories based on their use case, such as listing containers with the highest block IO or tracing DNS packets / exec system calls.
tini - "A tiny but valid init for containers."
Tini is meant to be run in a container - it spawns a single child and waits for it to exit all the while reaping zombies and performing signal forwarding. Written in C, and comes in both, dynamically and statically linked, forms.
dumb-init - "A minimal init system for Linux containers."
A simple process supervisor and init system designed to run as PID 1 inside minimal container environments. It is deployed as a small, statically-linked binary written in C.
pid1 - "Do signal handling and orphan reaping for Unix PID1 init processes."
A Haskell library, and an executable based on that library, for initializing signal handlers, spawning child processes, and reaping orphan processes.
icy/bocker & p8952/bocker - "Docker implemented in around 100 lines of bash."
Containers the hard way: Gocker - "Learning about containers and how they work by creating them the hard way."
Gocker is a "from scratch" implementation of the core functionalities of Docker - to provide an understanding of how exactly containers work at the Linux system call level. Written in Go.
barco - "Linux containers from scratch in C."
Much like boker or Gocker but in C.
contained.af - "A stupid game for learning about containers, capabilities, and syscalls."