A little bit of education about container systems in linux[1]. A container system is typically made up a number of components:<p><i>isolation layer</i>: the piece that limits privileges and resource usage. (On linux, this is usually handled by cgroups and the kernel, but could also be handled by something like kvm for vm-based containers)<p><i>raw container configuration</i>: Given an image and some metadata (like cpu limits), launch an isolated process. (On linux, this is usually handled by runc when working with cgroups)<p><i>container api daemon</i>: Manage the list of container processes and available images. Provide a unix socket based API for manipulating isolated processes, launching, deleting, connecting, etc. (In the case of docker, they provide a daemon which abstracts the containerd daemon, or you can use containerd alone without docker)<p><i>container command line tool</i>: Provide a user/developer interface to the three things above. This is the docker command. When you install containerd without docker this is the ctr command.<p>Docker, which is probably the most famous container distribution, pairs the docker command with the docker daemon to abstract away the containerd daemon, runc, and cgroups.<p>If you use containerd alone, you get ctr/containerd/runc/cgroups.<p>There's a standalone command line tool (crictl) which replaces both ctr and docker and can be used on top of either the docker daemon or containerd.<p>[1] Container systems seem to have a relatively complex abstraction over what is a relatively simple architecture.