These document describes concepts and terminology used by the Sysbox container runtime. We use these throughout our documents.
- Container Runtime
- Container Manager
- System Container
- Inner and Outer Containers
- Docker-in-Docker (DinD)
- Kubernetes-in-Docker (KinD)
The software that given the container's configuration and root filesystem (i.e., a directory that has the contents of the container) interacts with the Linux kernel to create the container.
Sysbox and the OCI runc are examples of container runtimes.
The entity that provides the container's configuration and root filesystem to the container runtime is typically a container manager (e.g., Docker, containerd).
The container manager manages the container's lifecycle, from image transfer and storage to container execution (by interacting with the container runtime).
Examples are Docker, containerd, etc.
The OCI runtime spec describes the interface between the container manager and the container runtime.
We call the containers deployed by Sysbox system containers, to highlight the fact that they can run not just micro-services (as regular containers do), but also system software such as Docker, Kubernetes, Systemd, inner containers, etc.
Traditionally, containers package a single application / micro-service. This makes sense for application containers, where multiple such containers form the application and separation of concerns is important.
However, system containers deviate from this a bit: they are meant to be used as light-weight, super-efficient "virtual hosts", and thus typically bundle multiple services.
Within the system container you can run the services of your choice (e.g., Systemd, sshd, Docker, etc.), and even launch (inner) containers just as you would on a physical host of VM. You can think of it as a "virtual host" or a "container of containers".
Of course, you can package a single service (e.g., Docker daemon) if you so desire; the choice is yours.
System containers provide an alternative to VMs in many scenarios, but are much more flexible, efficient, and portable. They offer strong isolation (in fact stronger than regular Docker containers) but to a lesser degree than the isolation provided by a VM.
For more info on system containers, see this blog article.
Sysbox is a container runtime that creates system containers.
When launching Docker inside a system container, terminology can quickly get confusing due to container nesting.
To prevent confusion we refer to the containers as the "outer" and "inner" containers.
-
The outer container is a system container, created at the host level; it's launched with Docker + Sysbox.
-
The inner container is an application container, created within the outer container (e.g., it's created by the Docker or Kubernetes instance running inside the system container).
DinD refers to deploying Docker (CLI + Daemon) inside Docker containers.
Sysbox supports DinD using well-isolated (unprivileged) containers and without the need for complex Docker run commands or specialized images.
KinD refers to deploying Kubernetes inside Docker containers.
Each Docker container acts as a K8s node (replacing a VM or physical host).
A K8s cluster is composed of one or more of these containers, connected via an overlay network (e.g., Docker bridge).
Sysbox supports KinD with high efficiency, using well-isolated (unprivileged) containers, and without the need for complex Docker run commands or specialized images.