Digital Garden

containerd

Was a part of docker

See architecture

nerdctl: a cli for containerd (remember to use namspaces)

Shim runtime API

Refer: https://github.com/containerd/containerd/tree/main/core/runtime/v2#architecture
The shim (runtime) v2 is introduced in containerd v1.2.0

containerd support multiple OCI runtimes such as runc, kata, runsc (gVisor).
As a common abstraction, containerd has provided the runtime API.

containerd, the daemon, does not directly launch containers. Instead, it acts as a higher-level manager or hub for coordinating the activities of containers and content, that lower-level programs, called “runtimes”, actually implement to start, stop and manage containers.

Two common patterns for implementation of a runtime are:

  • a single binary for runtime that both listens on the socket and creates/starts/stops the container
  • “shim+engine”: a separate runtime shim binary that listens on the socket, and invokes a separate runtime engine that creates/starts/stops the container

The “shim+engine” pattern is used because it makes it easier to integrate distinct runtimes implementing a specific runtime engine spec, such as the OCI runtime spec.
The ttRPC protocol can be handled via one runtime shim, while distinct runtime engine implementations can be used, as long as they implement the OCI runtime spec.
For example of this pattern,  runc, which implements the OCI runtime spec is a runtime engine. Thus it is not invoked directly by containerd; instead, it is invoked by containerd-shim-runc-v2 shim , which listens on the socket for requests from containerd.

Some common “runtimes”:

  1. runc = Runtime option : io.containerd.runc.v2 Shim BInary: containerd-shim-runc-v2 Shim Engine: runc
  2. kata = Runtime option : io.containerd.kata.v2 Shim BInary: containerd-shim-kata-v2 Engine: HyperVisor
  3. gVisor = Runtime option: io.containerd.runsc.v1 Shim BInary: containerd-shim-runsc-v1 Engine: runsc

The runtime (typically --runtime) can be selected when creating a container via one of the exposed containerd services (containerd client, CRI API,…), or via a client that calls into the containerd provided services.
The containerd clients are ( ctr, nerdctl, kubernetes, dockerd).

cri

Also see: https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/

The CRI interface for kubelets to work with containerd directly

containerd_cri

Also, the docker installed containerd (package containerd.io) disables the cri plugin in containerd (by modifying the /etc/containerd/config.toml config file ). Because cri plugin depends on cni (and maybe other libraries) which are not included when we install docker engine, so anyway the plugin won’t run

You can tell containerd to run cri plugin by modifying the config file, but it will probably fail

Graph View

Backlinks