Containerd is the software responsible for managing and running containers on a host system; in other words, it is a container runtime. It manages the container processes, snapshots, container metadata, and dependencies. It is responsible for downloading and extracting container images and setting up the container environment. It also interacts with other components, such as the operating system, the kernel, the network, and the storage.
There are many container runtimes available, but Containerd is the industry-standard runtime that supports the Open Container Initiative (OCI) Image Spec and Runtime Spec. This means that containerd can run any container image that conforms to the OCI standards and that it can work with any higher-level orchestration system that implements the OCI specifications, such as Kubernetes.
As of February 28, 2019, containerd is officially a graduated project within the Cloud Native Computing Foundation, following Kubernetes, Prometheus, Envoy, and CoreDNS. We’d like to thank the amazing containerd community for making this all possible and we’re excited for the future of the project.
Containerd is designed to be simple, robust, portable, and multi-tenant. It has a minimal and modular architecture that focuses on the core features of a container runtime, such as image management, container execution, storage and network interfaces, and low-level system integration. It also has a rich set of plugins that extend its functionality and compatibility with different platforms and environments. Containerd supports Linux, Windows, and ARM architectures and can run on various cloud providers, bare metal servers, and edge devices. Containerd also enables multiple users and applications to share the same container runtime instance while ensuring isolation and resource control.
How Does Containerd Work?
Containerd sits between Docker and runc. This is basically because when a request is sent to Docker, it passes the request to Containerd and then Containerd sends it to runc.
Containerd has different components that work together to ensure a consistent and efficient container runtime. Some of these components are:
- The containerd daemon (containerd): This is the core component that runs as a background process on the host system. It exposes a gRPC API for clients to communicate with it and perform various operations on containers and images. It also manages the container lifecycle, image storage, network interfaces, and low-level system integration.
- The containerd client (ctr): This is a command-line tool that can be used to interact with the containerd daemon. It can perform tasks such as creating, starting, stopping, and deleting containers; pulling and pushing images; and inspecting the state of the system. It can also be used as a library to build higher-level tools and applications that use containerd as the backend.
- The containerd plugins: These are modules that extend the functionality and compatibility of containerd. They are loaded by the containerd daemon at startup and can be configured via the configuration file (/etc/containerd/config.toml). Some of the plugins are:
- The CRI plugin: This is a plugin that implements the Kubernetes container runtime interface (CRI). It allows containerd to be used as the container runtime for Kubernetes clusters. It handles the CRI service requests from the kubelet and translates them into containerd API calls. It also supports features such as pod sandbox, container streaming, image authentication, and container logging.
- The snapshotters: These are plugins that provide different ways of managing the filesystem layers of container images. They are responsible for creating, mounting, and deleting snapshots that represent the state of the filesystem. They also support copy-on-write and remote mounting for efficient and fast image distribution. Some of the available snapshotters are overlayfs, btrfs, devmapper, zfs, and stargz.
- The content store: This is a plugin that provides a content-addressable storage for container images. It stores the image data as blobs, which are identified by a unique digest. It also supports image verification, encryption, and compression.
- The metadata store: This is a plugin that provides a key-value store for metadata related to containers and images. It stores information such as container configuration, state, and statistics, as well as image manifests, indexes, and leases.
- The containerd shims: These are processes that are created by the containerd daemon for each container. They are responsible for executing the container process using the OCI runtime spec and runc, as well as handling the IO and signals for the container. They also act as a proxy between the containerd daemon and the container process, allowing the daemon to be restarted without affecting the running containers.
Containerd also interacts with other software projects in the container ecosystem, such as Docker, Kubernetes, and runc. Some of the interactions are:
- Docker: Docker is a platform that allows users to build, run, and share containerized applications. Docker has used containerd as its container runtime since version 18.09. Docker communicates with containerd via the containerd API or the CRI plugin, depending on the mode (single-node or swarm). Docker also uses containerd’s content store and distribution features to manage images.
- Runc: Runc is a tool that runs containers according to the OCI runtime specification. Runc is used by containerd as the default runtime to execute the container process. Containerd launches runc via the containerd shims, passing the OCI specification and the bundle as arguments. Runc then creates the container namespace, mounts the filesystem, and runs the user-specified command.
What problems does containerd solve?
As stated earlier in this discussion, Containerd is one of the many container runtimes available in the market, each with its own pros and cons. Here are some of the comparisons between containerd and other popular container runtimes, such as Docker Engine and CRI-O.
Docker Engine:
Docker Engine is the most widely used container runtime, as it provides a comprehensive platform for building, running, and sharing containerized applications. Docker Engine uses containerd as its container runtime since version 18.09, which means that containerd is compatible with Docker images, commands, and APIs. However, Docker Engine also includes other components, such as docker CLI, docker-compose, docker-swarm, and docker-buildx, which adds more functionality and complexity to the platform.
Advantages of Docker Engine over containerd
- It has a larger and more active community and user base, which means more support and resources available.
- It has more features and tools for developing, testing, and deploying containerized applications, such as multi-stage builds, secrets management, and service discovery.
- It has a higher-level and user-friendly interface, which makes it easier to use and learn for beginners and non-technical users.
Disadvantages of Docker Engine over containerd
- It has a larger and more monolithic architecture, which means more overhead and potential security risks.
- It does not implement the Kubernetes container runtime interface (CRI), which means that it requires a compatibility layer (dockershim) to work with Kubernetes clusters. This layer is deprecated since Kubernetes 1.23, and Docker Engine is no longer supported as a runtime.
- It has more dependencies and components, which means more maintenance and compatibility issues.
CRI-O:
CRI-O is a lightweight and secure container runtime that implements the Kubernetes CRI. It is designed to be a native and optimized runtime for Kubernetes clusters, without any extra features or dependencies. CRI-O uses runc as its default runtime to execute containers, but it can also support other OCI-compliant runtimes, such as kata-containers and gvisor.
Advantages of CRI-O over containerd
- It has a smaller and simpler architecture, which means less overhead and attack surface.
- It has a tighter integration with Kubernetes, which means better performance and reliability.
- It has a stronger focus on security, which means more hardening and isolation features, such as SELinux, seccomp, and AppArmor.
Disadvantages of CRI-O over containerd
- It has a smaller and less diverse community and user base, which means less support and resources available.
- It has fewer features and tools for managing containers and images, such as content encryption, compression, and verification.
- It has a lower-level and less intuitive interface, which means more complexity and learning curve for users.
Biggest Adopters and Contributors of Containerd
Containerd has been adopted and contributed by many leading companies and organizations in the cloud and container ecosystem, such as Google, IBM, and Alibaba.
- Google: Google is one of the main contributors and users of containerd, as it uses containerd as the default container runtime for its Google Kubernetes Engine (GKE) and Cloud Run services. Google has also donated its container image format (stargz) and its remote snapshotter plugin to the containerd project, to improve the performance and efficiency of container image distribution and execution.
- IBM: IBM is one of the main adopters and supporters of containerd, as it uses containerd as the container runtime for its IBM Cloud Kubernetes Service and IBM Cloud Functions. IBM has also contributed to the development and testing of containerd, especially for the Windows and s390x platforms.
- Alibaba: Alibaba is one of the main adopters and innovators of containerd, as it uses containerd as the container runtime for its Alibaba Cloud Container Service and Alibaba Cloud Function Compute. Alibaba has also developed and open-sourced its own container image format (pouch) and its remote snapshotter plugin, to enable faster and more secure container image distribution and execution.
Getting Started with Containerd
containerd is available as a daemon for Linux and Windows. It manages the complete container lifecycle of its host system, from image transfer and storage to container execution and supervision to low-level storage to network attachments and beyond.
Step1: Install Contanerd on Linux
Download the latest release of Containerd
curl -L https://github.com/containerd/containerd/releases/download/v1.5.8/containerd-1.5.8-linux-amd64.tar.gz | tar xzv
Copy the binaries to /usr/local/bin
sudo cp bin/* /usr/local/bin/
Start the Containerd daemon
sudo containerd
Step2: Pull an image from a registry using the ctr command
Pull the Alpine image from Docker Hub
ctr image pull docker.io/library/alpine:latest
List the images in the local store
ctr image ls
Step3: Run a container from the image
Run a container from the Alpine image and execute /bin/sh
ctr run --rm docker.io/library/alpine:latest alpine /bin/sh
List the running containers
ctr container ls
To learn more you can refer to the official documentation.
FAQs
What is Containerd?
Containerd is a lightweight runtime managing the lifecycle of containers, used by Kubernetes, Docker, and cloud platforms for serverless functions and edge computing.
What operating systems is Containerd available for?
Containerd is available as a daemon for Linux and Windows.
Is containerd free to use?
Yes, Containerd is free to use and is open-source software with a permissive Apache 2.0 license. This allows anyone to use, modify, and distribute the software without paying any fees. However, it’s important to note that while the core Containerd runtime is free, there might be additional costs associated with using related technologies and services. For example, if you utilize Containerd with cloud-based container orchestration platforms like Kubernetes or serverless platforms like Google Cloud Run, you might incur charges for the underlying infrastructure resources consumed.
What is OCI?
Open Container Initiative (OCI): A collaborative project defining open standards for container formats and runtimes. This promotes interoperability and portability across different platforms.
We invite you to try out containerd and see for yourself how it can improve your container experience. You can also ask us your questions. You can reach us via the GitHub repository or the Slack channel. Thank you for reading this article.
