The boot process of containerd

The overall architecture diagram is as follows.

• Start with github.com/urfave/cli, with command
  • configCommand: related to containerd configuration
  • publishCommand: event related
  • ociHook: provides preStart, preStop, etc. container hook
• If no subcommand is executed, the default action is executed
  • Load the configuration file
  • Create top-level folder:
  • root = “/var/lib/containerd”
  • state = “/run/containerd”
  • Create /var/lib/containerd/tmpmounts
  • Clean up the temporary mount points under tmpmounts
• Create and initialize the containerd server
  • Apply the configuration settings to the server process.
  • If the OOMScore is set, it is applied to the process; the lower the OOMScore, the less likely it will be killed when the system runs out of memory.
  • If containerd’s Cgroup path is set, it will add its own processes to the cgroup. This also determines whether cgroup v1 or v2 is used.
  • Set a series of timeout parameters
  • Load plugins, containerd divides modules by plugins.
  • Loaded via the set plugin directory (default is /var/lib/containerd/plugins). go1.8 onwards doesn’t support this.
  • Register content plugin: content for the storage part of the containerred architecture.
  • Register metadata plugin: uses bolt, an embedded key/value database. Relies on content and snapshot plugin.
  • Register proxy plugin: proxy plugin supports both content, snapshot types. This is equivalent to starting a GRPC service, replacing the built-in content, snapshot plugin.
  • There are also a lot of plugins that are registered in the init method of the package
    • A lot of snapshot plugins: aufs, btrfs, devmapper, native, overlayfs, zfs
    • diff plugins: walking
    • GC plugins
    • a lot of service plugins: introspection, containers, content, diff, images, leases, namespaces, snapshots, tasks
    • runtime plugins: linux, task
    • monitoring plugins: cgroups
    • internal plugins: restart, opt
    • GRPC plugins: containers, content, diff, events, healthcheck, images, leases, namespaces, snapshots, tasks, version, introspection
    • CRI plugin: implements CRI and provides it for kubelet calls
• diff module registers stream processor, supports two
• application/vnd.oci.image.layer.v1.tar+encrypted
• application/vnd.oci.image.layer.v1.tar+gzip+encrypted
• Start TTRPC server: /run/containerd/containerd.sock.ttrpc
• Start GRPC server: /run/containerd/containerd.sock
• If TCP is enabled, the GRPC server will also listen to tcp.

At this point, containerd is ready to provide services to the public. The following is a brief explanation of some of the concepts or modules mentioned above.

• service: GRPC services depend on the corresponding service. service is used to encapsulate the internal implementation.
• TTRPC: TTRPC is optimized for low-memory environments by eliminating the net/http , net/http2 and grpc packages to achieve a lighter framing protocol, smaller binaries and less resident memory usage.
• storage module: contains three submodules: content, snapshot and diff.
  • content: content is responsible for the entire image storage process.
  • snapshot: To ensure that the data in the image layer is immutable, a snapshot is created from the layer when the container is run.
  • diff: The diff module implements two functions: diff and apply. diff is used to compare the differences between the upper and lower layers and then package the layer according to the OCI specification. apply is used to mount a layer according to the underlying federated file system.
• metadata module: Contains images and containers sub-templates.
  • images: Stores image related metadata.
  • containers: Stores metadata about containers.
• tasks module: The operation of a container is abstracted into a task.
• event module: Provides publish-subscribe functionality for events. Third parties can get events in containerd through event, such as image creation, update, container creation, deletion, etc.