Learn ContainerD

History of ContainerD Origin from Docker: The origins of containerd can be traced back to Docker, the popular container platform. Docker initially included all components required to run a container in a single monolithic binary, which included the container runtime. As Docker grew, there was a need to break down this monolithic structure into more manageable, modular components. Announcement and Spin-Off (2016): Docker announced containerd in December 2016 as a core component split off from the Docker Engine. This move was part of Docker's effort to modularize its platform. containerd was designed to manage the entire container lifecycle, including image transfer and storage, container execution and supervision, low-level storage, and network attachments. Donation to CNCF (2017): In March 2017, Docker donated containerd to the Cloud Native Computing Foundation (CNCF), the same foundation that hosts Kubernetes. This move was aimed at fostering an open, neutral, and community-driven base for container operations. Graduation from CNCF (2019): containerd graduated from CNCF in February 2019, which indicated its maturity, stable API, and growing adoption. Graduation from CNCF is a significant milestone that reflects a project’s sustainability and adherence to certain standards of governance. Adoption and Usage: Over the years, containerd has seen significant adoption in the industry. It is used by Kubernetes, as well as cloud providers and Linux distributions for their container operations. This wide adoption is due to its simplicity, robustness, and the strong community support it has garnered. This diagram represents the architecture of containerd, an industry-standard core container runtime. It is designed to be less opinionated and can be used as a base for building a more complex container platform. Let's break down the architecture depicted in the image: Ecosystem Layer The topmost layer is the ecosystem that interacts with containerd. It includes: Platforms: Cloud platforms and container orchestration systems that use containerd as their runtime, such as Google Cloud Platform, Docker, IBM Cloud, Microsoft Azure, Alibaba Cloud, AWS, and others. Clients: Tools that interact with containerd, like kubectl for Kubernetes, Docker CLI, ctr (containerd's own CLI tool), BuildKit for building containers, and others. CRI Runtime: containerd is compatible with the Kubernetes Container Runtime Interface (CRI), making it possible to use containerd as the runtime in Kubernetes. containerd Layer This is the core of containerd, divided into several components: API: The gRPC API layer through which clients communicate with containerd. It defines service handlers for various container management tasks. Service Handlers: These are gRPC services that handle API requests. They include services for managing containers, images, snapshots, tasks, namespaces, and more. Core Layer This is where the main functionality of containerd resides: Services: These are the backend services that do the actual work. They include: Containers Service: Manages container metadata. Content Service: Manages the storage and retrieval of content like layers and config. Diff Service: Handles layer diff computations. Images Service: Manages image metadata. Leases Service: Manages client leases for resources. Namespaces Service: Provides multi-tenancy by segregating resources per namespace. Snapshots Service: Manages filesystem snapshots. Tasks Service: Manages the execution of containers. Backend Layer The backend consists of the components that interact with the host system: Content Store: Storage for content like container images. This can be local storage or a plugin. Snapshotter: Handles the creation of filesystem snapshots. There are various snapshotter plugins available, including overlay, btrfs, devmapper, native, and windows. Runtime: This is where the containers are actually run. containerd supports multiple runtimes: runc: The default OCI runtime for Linux containers. runhcs: A runtime for running Windows containers. Kata Containers: Provides lightweight VMs that offer more isolation than traditional container environments. Firecracker: A microVM manager for creating and managing microVMs. gVisor: A user-space kernel for providing sandboxed environments. V2 shim client: A newer version of the shim that manages the lifecycle of the containers and the host processes related to it. System Layer The bottom layer represents the system dependencies: Operating Systems: The diagram shows containerd being compatible with ARM and Intel architectures, indicating cross-platform support. Linux Penguins: Symbolizes that containerd is a Linux-native technology, but it also supports Windows as indicated by the "windows" snapshotter. Metrics Off to the side, there is a connection to Prometheus, which is a monitoring system that collects metrics. containerd has built-in support for exporting metrics that Prometheus can scrape and use for monitoring and alerting. Overall, containerd is designed to handle the lifecycle of containers and images in a container system, manage storage and execution, and allow for extensive customization through plugins and external tooling. It is a key component in many modern container platforms, offering a balance between functionality and flexibility. install ruc create directory once installed, you can start using runc: Creating a Container Create a Root Filesystem: You need a root filesystem for your container. You can create a simple one or use an existing Docker image. Example: mkdir rootfs and unpack a Docker image into it using docker export and tar. Export the filesystem of an existing Docker image (e.g., alphine) it will give us two files check it out config.json file config file in depth ociVersion ociVersion: Specifies the OCI Runtime Specification version that the configuration is compatible with. process This section details how the process inside the container should be run. terminal: If set to true, a terminal is attached to the process. user: Specifies the UID and GID for the process. args: Arguments for the process to be run inside the container. In your case, it starts a shell (sh). env: Environment variables. cwd: Current working directory inside the container. capabilities: Linux capabilities that the process inside the container can use. rlimits: Resource limits for the process (e.g., number of open files). noNewPrivileges: If true, the process is not allowed to gain new privileges. root path: The path to the root filesystem relative to the location of the config.json file. Here, it's set to use the rootfs directory. readonly: If true, the root filesystem is mounted as read-only. hostname hostname: The hostname set for the container. mounts This section defines filesystems or directories that are mounted in the container. destination: Where the mount will be placed inside the container. type: The type of the filesystem to be mounted (e.g., proc, tmpfs). source: The source of the mount. options: Mount options. linux This section contains Linux-specific configurations. resources: Controls how the container can interact with system resources. namespaces: Namespaces provide isolation for the container. Common namespaces include pid, network, ipc, uts, mount, and cgroup. maskedPaths: Paths that should be hidden from the container. readonlyPaths: Paths that should be read-only inside the container. runc run - create and run a container lets create list all namespaces list of all running processes on your system, including details about the user running each process, CPU and memory usage, the process ID (PID), the parent process ID (PPID), and more. start container and check state of container kill the container 1 process sangam@sangam:$ sudo runc kill container1 SIGKILL Cheatsheet - Runc Commands for Managing Containers The following table provides an overview of various runc commands and their usage, demonstrated with an Alpine Linux container named container1. Command Description Example Usage ------------------------------------------------------------------------------------------------------------------------------- spec Create a new specification file for the container. sudo runc spec create Create a container instance based on the spec file. sudo runc create container1 start Start the container's init process. sudo runc start container1 list List containers managed by runc. sudo runc list exec Execute a command inside the running container. sudo runc exec container1 ls state Output the state of a specified container. sudo runc state container1 pause Pause all processes within the container. sudo runc pause container1 resume Resume all processes that have been previously paused. sudo runc resume container1 delete Delete the container (only if it's not running). sudo runc delete container1 Remember to edit the config.json file to specify the Alpine Linux root filesystem and adjust other configurations as necessary for your setup. update ubuntu server Install the necessary packages install docker Install Containerd Configure ContainerD ContainerD Configuration Overview Table of Contents General Configuration CGroup Debug GRPC Metrics Plugins Proxy Plugins Stream Processors Timeouts TTRPC General Configuration Key Description --- ----------- disabledplugins List of plugins to be disabled. requiredplugins List of required plugins. imports List of imports from other configurations. oomscore Out-Of-Memory score for ContainerD processes. plugindir Directory for ContainerD plugins. root Directory for ContainerD's persistent state. state Directory for ContainerD's runtime state. version Configuration file format version. CGroup Key Description --- ----------- path Custom path for cgroup. Debug Key Description --- ----------- address Socket address for debug service. format Log format for debug service. gid Group ID for debug service. level Debug level. uid User ID for debug service. GRPC Key Description --- ----------- address Socket address for GRPC communication. maxrecvmessagesize Maximum receive message size. maxsendmessagesize Maximum send message size. tcpaddress TCP address for GRPC. tcptls TLS settings for TCP GRPC. uid, gid User/Group ID for GRPC socket. Metrics Key Description --- ----------- address Address for exporting metrics. grpchistogram Enable GRPC histogram metrics. Plugins This section is extensive and contains configurations for various ContainerD plugins. Only key plugins and configurations are listed here. io.containerd.gc.v1.scheduler Garbage collection settings. io.containerd.grpc.v1.cri Settings for Container Runtime Interface (CRI), crucial for Kubernetes. Runtimes (runc, etc.) Define and configure container runtimes. Proxy Plugins Key Description --- ----------- pluginname Configuration for specific proxy plugin. Stream Processors Key Description --- ----------- processorname Configuration for specific stream processor. Timeouts Key Description --- ----------- timeoutname Various timeout settings for ContainerD operations. TTRPC Key Description --- ----------- address Address for TTRPC communication. uid, gid User/Group ID for TTRPC socket. Verify ContainerD CLI - Ctr available on your system ctr Command Examples for ContainerD ctr is a command-line utility provided by ContainerD for interacting with the ContainerD daemon. It's used for development, debugging, and low-level container operations. Below are some common examples of how to use ctr commands. Table of Contents List Containers Run a Container Pull an Image List Images Remove an Image Create a Snapshot Push an Image Execute Command in Container View Container Logs Stop a Container Delete a Container List Containers Pull an Image Run a Container List Images Remove an Image Create a Snapshot Push an Image Execute Command in Container View Container Logs Stop a Container Delete a Container Ctr plugins pull images of all platfroms export as tar extract the tar file skiped unwanted file and see what