Coding With Fun
Home Docker Django Node.js Articles Python pip guide FAQ Policy

What's the difference between runtime and runtime in containers?


Asked by Houston Dudley on Dec 15, 2021 FAQ



You may have heard the term “runtime” referring to the lifecycle phase of a program or the usage of a specific language to execute a program. A container runtime functions similarly to the latter—it’s software that runs and manages the components required to run containers.
In this manner,
containerd is a high-level container runtime that came from Docker, and implements the CRI spec. It pulls images from registries, manages them and then hands over to a lower-level runtime, which actually creates and runs the container processes. containerd was separated out of the Docker project, to make Docker more modular.
Thereof, A container runtime is responsible for all the parts of running a container that isn't actually running the program itself. As we will see throughout this series, runtimes implement varying levels of features, but running a container is actually all that's required to call something a container runtime.
Subsequently,
I'll hopefully show that neither side is totally wrong and I'll use the term pretty broadly in this blog post. When folks think of container runtimes, a list of examples might come to mind; runc, lxc, lmctfy, Docker (containerd), rkt, cri-o. Each of these is built for different situations and implements different features.
In respect to this,
Kubernetes is shifting to the Container Runtime Interface (CRI), which supports a broader set of container runtimes with smooth interoperability between different runtimes. Because Docker builds an OCI-standard container image, those images will run on any OCI-compliant container runtime.