Most people know Docker as the container runtime but you might be surprised to learn that the underlying runtime, Docker uses is containerd. There are various container runtimes in the market, however, Docker indeed revolutionized and industrialized containers since its introduction in 2013.
A container runtime is a software package that knows how to leverage specific features on a supported operating system to run the containers. Containers provide a standardized and efficient way to package, deploy, and manage applications, offering benefits such as portability, scalability, isolation, resource efficiency, and consistent environments across different stages of the software development lifecycle.
Container runtime acts as a middle layer between the host OS and container instances. Most of them conforms to the Container Runtime Interface or CRI. In this article, we will learn about various container runtimes and their use-cases.
Container Runtimes Categories
High-Level Container Runtimes
Docker Engine
The Docker engine is still the best-known container runtime platform in the mainstream. Docker is a high-level runtime that enables the creation and management of lightweight, isolated containers for applications and services. It provides a simplified and consistent environment for running software, abstracting away the complexities of the underlying infrastructure. Docker allows developers to package their applications with all their dependencies into a portable container, ensuring consistent behavior across different environments. These containers are isolated from one another and can be easily deployed, scaled, and managed, making Docker a popular choice for deploying and running applications in various settings, from development to production environments.
Podman
Podman is also a high-level runtime that provides a containerization solution similar to Docker. It allows users to create, run, and manage containers for applications and services. Podman is compatible with the Open Container Initiative (OCI) standards and can run Docker-formatted container images. It provides a command-line interface and API for container management, including functions like creating, starting, stopping, and removing containers.
One key distinction of Podman is that running containers does not require a separate daemon process. It operates as a daemonless container engine, meaning it runs containers as individual processes without the need for a centralized daemon. Podman interacts with the Linux kernel directly through runc.
CRI-O
CRI-O is another high-level runtime, specifically designed to run containers that adhere to the Kubernetes Container Runtime Interface (CRI) specification. It focuses on providing a lightweight, stable, and secure runtime environment for running containers within Kubernetes clusters.
CRI-O enables the execution of containers by interacting with the Kubernetes control plane. It adheres to the CRI standard, which defines the interface between Kubernetes and the container runtime. This ensures compatibility and interoperability with Kubernetes, allowing users to seamlessly run and manage containers within their Kubernetes environments.
Similar to Docker and Podman, CRI-O offers features such as container isolation, image management, and container lifecycle management. However, CRI-O is specifically tailored for Kubernetes deployments and is optimized for use within the Kubernetes ecosystem. It provides a minimal footprint, improved security, and compatibility with container images that adhere to the Open Container Initiative (OCI) standards.
Low-Level Container Runtimes
Any container engine that implements the Open Container Initiative (OCI) runtime specification is considered to be a low-level container runtime. These are the basic building blocks that make containers possible and do the actual unpacking, creating, starting, and stopping of the container instances:
runc
runc is a low-level runtime that implements the OCI runtime specification. It provides the foundation for running containers by orchestrating container execution and lifecycle management. runc is focused on simplicity, portability, and standardization, allowing different containerization platforms and tools to utilize a common runtime interface.
crun
crun is another low-level runtime in C that implements the OCI runtime specification. It is designed for lightweight and fast container execution, optimized for performance and resource efficiency. crun aims to be a simple and minimalistic alternative to runc, focusing on speed and minimal overhead. It provides a compatible runtime environment for running containers while prioritizing simplicity and performance.
runhcs
runhcs (runC with Hypervisor-based Containers) is an experimental project that extends the functionality of runC to support hypervisor-based containers, such as those utilizing the Kernel-based Virtual Machine (KVM). It leverages the same OCI runtime specification, allowing users to run containers with the added isolation and security benefits of a hypervisor. runhC aims to provide a consistent and familiar interface for managing containers while leveraging the capabilities of hardware virtualization. Please note that runhcs is an experimental project, and its adoption and usage may vary. Simply, you can understand as a Windows containers counterpart of runc.
containerd
Containerd is on the line between low-level and high-level. It actually leans more toward a high-level container runtime because it provides an API layer on top of an OCI-compatible runtime, but we will include it here because you don’t really interact with it directly. There’s always an external layer that you use to interact with it, such as a CLI (like nerdctl or ctr) or CRI on Kubernetes. It is one of the most popular option after Docker engine and it is a CNCF graduated project since 2019.
Process-based vs VM-based Runtimes
| Process-based Runtimes | Virtual Machine (VM)-based Runtimes |
| Docker, Container-d, CRI-O | Kata, Firecracker |
| They rely on operating system features such as namespaces and c-groups to provide container isolation and resource management. | run containers within lightweight virtual machines. These runtimes leverage hypervisor technologies to create and manage these VMs |
| lightweight | enhanced isolation and security |
| provide fast startup times | scenarios where strict isolation is a priority |
| suitable for most container workloads |
Use cases
There are several popular container runtimes available, each with its own strengths and use cases. Here are some of the widely used container runtimes and their associated use cases:
| Docker | Containerd | CRI-O | rocket(rkt) |
| Development and testing environments | designed to be lightweight and focuses on executing containers reliably and efficiently | It is specifically designed to work with Kubernetes | developed by CoreOS (now part of Red Hat) |
| enables the deployment of individual microservices | It is the default container runtime in Kubernetes | provides a runtime environment optimized for Kubernetes-specific use cases. | rkt emphasizes strong security features, such as container signature verification and isolation mechanisms |
| often used in CI/CD workflows | can be used in container orchestration | Security-focused deployments | |
| deploying applications across different cloud providers or hybrid environments. | It aims to provide a minimal runtime |
It's worth noting that container runtimes like Docker and containerd support the Open Container Initiative (OCI) image format, which allows for interoperability between different runtimes and ensures compatibility across the container ecosystem. This means that containers built with one runtime can be executed with another runtime that supports OCI images.
Conclusion
Container runtimes have revolutionized how software is developed, deployed, and managed. Docker, Podman, CRI-O, containerd, runc, and runhcs are key players in the containerization ecosystem. Docker, with its user-friendly interface, has been instrumental in popularizing containers. Podman offers a daemonless alternative with Docker compatibility, while CRI-O caters specifically to Kubernetes environments. runc and runhcs provide low-level implementations, promoting standardization and flexibility. Each runtime serves distinct purposes, empowering developers with options for streamlined container management, improved portability, and efficient resource utilization across various deployment scenarios.
About the Guest Author
Smita, previously an IT Trainer, dedicated numerous years to assisting individuals and organizations in gaining knowledge about diverse technologies and software development methodologies. Currently, her growing fascination lies in the realm of DevOps, prompting her to delve deeper into research within this field. Smita possesses a profound passion for writing and takes pleasure in disseminating the knowledge she acquires along her journey.
Credits: All images are taken from the respective project documentation.