Convert Figma logo to code with AI

containerd logocontainerd

An open and reliable container runtime

18,858
3,600
18,858
427
View on GitHub

Top Related Projects

moby's avatar

moby

70,416

The Moby Project - a collaborative project for the container ecosystem to assemble container-based systems

kubernetes's avatar

kubernetes

115,996

Production-Grade Container Scheduling and Management

docker-archive's avatar

docker-ce

5,771

:warning: This repository is deprecated and will be archived (Docker CE itself is NOT deprecated) see the https://github.com/docker/docker-ce/blob/master/README.md :warning:

cri-o's avatar

cri-o

5,464

Open Container Initiative-based implementation of Kubernetes Container Runtime Interface

opencontainers's avatar

runc

12,469

CLI tool for spawning and running containers according to the OCI specification

Quick Overview

Containerd is an industry-standard container runtime with an emphasis on simplicity, robustness, and portability. 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.

Pros

  • High performance and low overhead due to its minimalist design
  • Highly extensible through a plugin architecture
  • Strong focus on OCI (Open Container Initiative) standards compliance
  • Widely adopted and supported by major cloud providers and container orchestration platforms

Cons

  • Steeper learning curve compared to higher-level container runtimes like Docker
  • Limited built-in functionality, requiring additional tools for a complete container management solution
  • Documentation can be sparse or technical for newcomers
  • Requires more manual configuration compared to more user-friendly alternatives

Getting Started

To get started with containerd:

  1. Install containerd:
sudo apt-get update
sudo apt-get install containerd
  1. Start the containerd service:
sudo systemctl start containerd
  1. Verify the installation:
ctr version
  1. Pull and run a container:
sudo ctr images pull docker.io/library/hello-world:latest
sudo ctr run docker.io/library/hello-world:latest hello-world

For more advanced usage and configuration, refer to the official containerd documentation.

Competitor Comparisons

moby logo

moby

70,416

The Moby Project - a collaborative project for the container ecosystem to assemble container-based systems

Pros of Moby

  • More comprehensive container ecosystem, including image building and higher-level orchestration features
  • Extensive documentation and community support
  • Broader compatibility with various container formats and runtimes

Cons of Moby

  • Larger codebase and more complex architecture
  • Slower release cycle and potentially longer time to address issues
  • Higher resource overhead due to additional features

Code Comparison

Moby (Docker Engine) configuration example:

version: '3'
services:
  web:
    image: nginx:latest
    ports:
      - "80:80"

Containerd configuration example:

[plugins."io.containerd.grpc.v1.cri"]
  [plugins."io.containerd.grpc.v1.cri".containerd]
    snapshotter = "overlayfs"
    [plugins."io.containerd.grpc.v1.cri".containerd.runtimes]
      [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
        runtime_type = "io.containerd.runc.v2"

Key Differences

Moby (Docker Engine) provides a higher-level abstraction for container management, including image building and orchestration features. Containerd, on the other hand, focuses on being a lightweight, portable runtime for containers, offering a more streamlined approach to container execution and management.

Moby is better suited for users who need a complete container solution with built-in tooling, while Containerd is ideal for those seeking a minimal, efficient container runtime that can be integrated into larger systems or custom container platforms.

kubernetes logo

kubernetes

115,996

Production-Grade Container Scheduling and Management

Pros of Kubernetes

  • Comprehensive container orchestration platform with advanced features like auto-scaling, load balancing, and self-healing
  • Large ecosystem with extensive tooling and community support
  • Declarative configuration and infrastructure-as-code capabilities

Cons of Kubernetes

  • Steeper learning curve and more complex setup compared to Containerd
  • Higher resource overhead, especially for smaller deployments
  • Potential overkill for simple container management needs

Code Comparison

Kubernetes manifest example:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Containerd CLI example:

ctr images pull docker.io/library/nginx:latest
ctr run --detach docker.io/library/nginx:latest nginx

Kubernetes offers a more declarative approach with YAML manifests, while Containerd provides a simpler CLI-based container management experience. Kubernetes is better suited for complex, distributed applications, whereas Containerd is more appropriate for lightweight container runtime needs or as a building block for higher-level orchestration systems.

docker-archive logo

docker-ce

5,771

:warning: This repository is deprecated and will be archived (Docker CE itself is NOT deprecated) see the https://github.com/docker/docker-ce/blob/master/README.md :warning:

Pros of docker-ce

  • More user-friendly and easier to set up for beginners
  • Includes a complete container management ecosystem (Docker Compose, Docker Swarm)
  • Offers a higher-level abstraction for container operations

Cons of docker-ce

  • Larger footprint and more resource-intensive
  • Less flexible for advanced use cases and custom integrations
  • Development has slowed down compared to containerd

Code comparison

docker-ce:

FROM ubuntu:20.04
RUN apt-get update && apt-get install -y nginx
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

containerd:

import (
    "github.com/containerd/containerd"
    "github.com/containerd/containerd/cio"
)
container, err := client.NewContainer(ctx, "nginx")
task, err := container.NewTask(ctx, cio.NewCreator(cio.WithStdio))

Summary

Docker CE provides a more comprehensive and user-friendly container solution, while containerd offers a lightweight, flexible runtime for advanced users and integrations. Docker CE is better suited for beginners and small to medium-sized projects, whereas containerd is ideal for large-scale deployments and custom container orchestration systems.

cri-o logo

cri-o

5,464

Open Container Initiative-based implementation of Kubernetes Container Runtime Interface

Pros of CRI-O

  • Designed specifically for Kubernetes, offering tighter integration
  • Lighter weight and more resource-efficient
  • Simpler architecture, potentially easier to maintain

Cons of CRI-O

  • Less widely adopted compared to containerd
  • Fewer features and less flexibility for non-Kubernetes use cases
  • Smaller ecosystem and community support

Code Comparison

CRI-O (Go):

func (s *Server) CreateContainer(ctx context.Context, req *pb.CreateContainerRequest) (*pb.CreateContainerResponse, error) {
    // Container creation logic
}

containerd (Go):

func (c *Client) NewContainer(ctx context.Context, id string, opts ...NewContainerOpts) (Container, error) {
    // Container creation logic
}

Both projects use Go and have similar function signatures for container creation. CRI-O's implementation is more tightly coupled with Kubernetes-specific concepts, while containerd's is more generic.

containerd offers a broader range of features and is more widely adopted, making it suitable for various container runtime scenarios. CRI-O, on the other hand, is optimized for Kubernetes environments, providing a more streamlined and efficient solution for that specific use case.

opencontainers logo

runc

12,469

CLI tool for spawning and running containers according to the OCI specification

Pros of runc

  • Lightweight and focused on container runtime functionality
  • Direct low-level control over container execution
  • Easier to integrate into custom container solutions

Cons of runc

  • Limited scope compared to containerd's broader feature set
  • Requires additional components for full container management
  • Less abstraction, potentially more complex for high-level use cases

Code Comparison

runc (simplified example):

spec, err := loadSpec(context)
if err != nil {
    return err
}
status, err := startContainer(spec, context)

containerd (simplified example):

client, err := containerd.New("/run/containerd/containerd.sock")
container, err := client.NewContainer(ctx, "example")
task, err := container.NewTask(ctx, cio.NewCreator(cio.WithStdio))
err = task.Start(ctx)

Key Differences

  • runc focuses on container runtime execution
  • containerd provides a higher-level API for container lifecycle management
  • containerd includes additional features like image management and networking
  • runc is often used as a lower-level component within containerd
  • containerd offers more abstraction and integration with container ecosystems

Both projects are essential in the container ecosystem, with runc serving as a foundational runtime and containerd providing a more comprehensive container management solution.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

containerd banner light mode containerd banner dark mode

PkgGoDev Build Status Nightlies Go Report Card CII Best Practices OpenSSF Scorecard Check Links

containerd is an industry-standard container runtime with an emphasis on simplicity, robustness, and portability. It is available as a daemon for Linux and Windows, which can manage the complete container lifecycle of its host system: image transfer and storage, container execution and supervision, low-level storage and network attachments, etc.

containerd is a member of CNCF with 'graduated' status.

containerd is designed to be embedded into a larger system, rather than being used directly by developers or end-users.

architecture

Announcements

containerd v2.0 is now released!

See docs/containerd-2.0.md.

Now Recruiting

We are a large inclusive OSS project that is welcoming help of any kind shape or form:

  • Documentation help is needed to make the product easier to consume and extend.
  • We need OSS community outreach/organizing help to get the word out; manage and create messaging and educational content; and help with social media, community forums/groups, and google groups.
  • We are actively inviting new security advisors to join the team.
  • New subprojects are being created, core and non-core that could use additional development help.
  • Each of the containerd projects has a list of issues currently being worked on or that need help resolving.
    • If the issue has not already been assigned to someone or has not made recent progress, and you are interested, please inquire.
    • If you are interested in starting with a smaller/beginner-level issue, look for issues with an exp/beginner tag, for example containerd/containerd beginner issues.

Getting Started

See our documentation on containerd.io:

To get started contributing to containerd, see CONTRIBUTING.

If you are interested in trying out containerd see our example at Getting Started.

Nightly builds

There are nightly builds available for download here. Binaries are generated from main branch every night for Linux and Windows.

Please be aware: nightly builds might have critical bugs, it's not recommended for use in production and no support provided.

Kubernetes (k8s) CI Dashboard Group

The k8s CI dashboard group for containerd contains test results regarding the health of kubernetes when run against main and a number of containerd release branches.

Runtime Requirements

Runtime requirements for containerd are very minimal. Most interactions with the Linux and Windows container feature sets are handled via runc and/or OS-specific libraries (e.g. hcsshim for Microsoft). The current required version of runc is described in RUNC.md.

There are specific features used by containerd core code and snapshotters that will require a minimum kernel version on Linux. With the understood caveat of distro kernel versioning, a reasonable starting point for Linux is a minimum 4.x kernel version.

The overlay filesystem snapshotter, used by default, uses features that were finalized in the 4.x kernel series. If you choose to use btrfs, there may be more flexibility in kernel version (minimum recommended is 3.18), but will require the btrfs kernel module and btrfs tools to be installed on your Linux distribution.

To use Linux checkpoint and restore features, you will need criu installed on your system. See more details in Checkpoint and Restore.

Build requirements for developers are listed in BUILDING.

Supported Registries

Any registry which is compliant with the OCI Distribution Specification is supported by containerd.

For configuring registries, see registry host configuration documentation

Features

For a detailed overview of containerd's core concepts and the features it supports, please refer to the FEATURES.MD document.

Releases and API Stability

Please see RELEASES.md for details on versioning and stability of containerd components.

Downloadable 64-bit Intel/AMD binaries of all official releases are available on our releases page.

For other architectures and distribution support, you will find that many Linux distributions package their own containerd and provide it across several architectures, such as Canonical's Ubuntu packaging.

Enabling command auto-completion

Starting with containerd 1.4, the urfave client feature for auto-creation of bash and zsh autocompletion data is enabled. To use the autocomplete feature in a bash shell for example, source the autocomplete/ctr file in your .bashrc, or manually like:

$ source ./contrib/autocomplete/ctr

Distribution of ctr autocomplete for bash and zsh

For bash, copy the contrib/autocomplete/ctr script into /etc/bash_completion.d/ and rename it to ctr. The zsh_autocomplete file is also available and can be used similarly for zsh users.

Provide documentation to users to source this file into their shell if you don't place the autocomplete file in a location where it is automatically loaded for the user's shell environment.

CRI

cri is a containerd plugin implementation of the Kubernetes container runtime interface (CRI). With it, you are able to use containerd as the container runtime for a Kubernetes cluster.

cri

CRI Status

cri is a native plugin of containerd. Since containerd 1.1, the cri plugin is built into the release binaries and enabled by default.

The cri plugin has reached GA status, representing that it is:

See results on the containerd k8s test dashboard

Validating Your cri Setup

A Kubernetes incubator project, cri-tools, includes programs for exercising CRI implementations. More importantly, cri-tools includes the program critest which is used for running CRI Validation Testing.

CRI Guides

Communication

For async communication and long-running discussions please use issues and pull requests on the GitHub repo. This will be the best place to discuss design and implementation.

For sync communication catch us in the #containerd and #containerd-dev Slack channels on Cloud Native Computing Foundation's (CNCF) Slack - cloud-native.slack.com. Everyone is welcome to join and chat. Get Invite to CNCF Slack.

Join our next community meeting hosted on Zoom. The schedule is posted on the CNCF Calendar (search 'containerd' to filter).

Security audit

Security audits for the containerd project are hosted on our website. Please see the security page at containerd.io for more information.

Reporting security issues

Please follow the instructions at containerd/project

Licenses

The containerd codebase is released under the Apache 2.0 license. The README.md file and files in the "docs" folder are licensed under the Creative Commons Attribution 4.0 International License. You may obtain a copy of the license, titled CC-BY-4.0, at http://creativecommons.org/licenses/by/4.0/.

Project details

containerd is the primary open source project within the broader containerd GitHub organization. However, all projects within the repo have common maintainership, governance, and contributing guidelines which are stored in a project repository commonly for all containerd projects.

Please find all these core project documents, including the:

information in our containerd/project repository.

Adoption

Interested to see who is using containerd? Are you using containerd in a project? Please add yourself via pull request to our ADOPTERS.md file.