Getting started with Containerd

Getting started with Containerd

In the last article, we gossip about the past and present of containerd, and its position in the current cloud native ecosystem (I have been accidentally pigeoning for so long, my brother is deeply ashamed, and now I attach a link to this article~). So let's take a look at how to use containerd in this article!

Installation and deployment

Installation package download

Containerd provides two compressed packages, one is containerd-${version}-${os}-${arch}.tar.gz , which only contains containerd-related binary files; the other is cri-containerd-cni-${version}-${os}-${arch}.tar.gz , which is a relatively complete compressed package. In addition to containerd-related binaries, it also contains runc (the runtime of the underlying container on which containerd runs) and the binary of related commands (such as ctr ). If it is run as a K8s container, it is recommended to directly choose the second type of compressed package. The compressed package addresses are in github release .

Tips, currently github containerd in the release version only supports amd64 architecture (ie x86), the team only openlab maintained on CI processes arm architecture: arm CI record . At present, on my Raspberry Pi, because of the installation and deployment of K3s that rely on containerd, containerd of the arm architecture is indirectly deployed.

After downloading, unzip and configure environment variables, you can use the cri command to view the version of containerd

$ export PATH=$PATH:/usr/local/bin:/usr/local/sbin
$ ctr version
Client:
  Version:  1.3.7
  Revision: 8fba4e9a7d01810a393d5d25a3621dc101981175

Server:
  Version:  1.3.7
  Revision: 8fba4e9a7d01810a393d5d25a3621dc101981175
  UUID: c05a8353-d52c-44cd-88fe-af5b58f32b5b

Configuration related

The configuration file of containerd is /etc/containerd/config.toml default. You can also use the command containerd config default > /etc/containerd/config.toml generate a default configuration file. The simplest configuration file is as follows:

subreaper = true
oom_score = -999

[debug]
        level = "debug"

[metrics]
        address = "127.0.0.1:1338"

[plugins.linux]
        runtime = "runc"
        shim_debug = true

Start containerd

In a linux system, you can directly use systemd to start the daemon, and the systemd configuration file is also in the compressed package:

[Unit]
Description=containerd container runtime
Documentation=https://containerd.io
After=network.target local-fs.target

[Service]
ExecStartPre=-/sbin/modprobe overlay
ExecStart=/usr/bin/containerd

Type=notify
Delegate=yes
KillMode=process
Restart=always
# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
LimitNPROC=infinity
LimitCORE=infinity
LimitNOFILE=1048576
# Comment TasksMax if your systemd version does not supports it.
# Only systemd 226 and above support this version.
TasksMax=infinity

[Install]
WantedBy=multi-user.target

After starting, you can use the command systemctl status containerd view the running status.

In the above configuration file, there is Delegate , which is set to yes means that the system allows Containerd to create Cgroups and adds the child processes created by the containerd main process (that is, the container process) to its own Cgroups. Otherwise, the container process will be moved to its own cgroups by systemd, and the main containerd process will not be able to read the resource status of the child process.

In addition, there is a KillMode , set to process means that if the main containerd process exits or is killed, it will not affect the child processes it creates, so that containerd and the container are independent of each other.

storage

Like docker, containerd persists container-related data in /var/lib/containerd/ (docker defaults to /var/lib/docker/ ), but the stored data is quite different. The containerd directory contains all plug-in data (the same idea as the containerd architecture diagram, everything is plug-in), which includes the plug-in's snapshots, metadata, etc. Among them, the log of containerd shim is saved in the io.containerd.runtime.v1.linux

.
├── io.containerd.content.v1.content
│   └── ingest
├── io.containerd.grpc.v1.introspection
│   └── uuid
├── io.containerd.metadata.v1.bolt
│   └── meta.db
├── io.containerd.runtime.v1.linux
│   └── moby
├── io.containerd.runtime.v2.task
├── io.containerd.snapshotter.v1.aufs
│   └── snapshots
├── io.containerd.snapshotter.v1.btrfs
├── io.containerd.snapshotter.v1.native
│   └── snapshots
├── io.containerd.snapshotter.v1.overlayfs
│   └── snapshots
└── tmpmounts

ctr instruction use

After starting the main process of containerd, we can run the container happily. ctr is a command line tool developed by containerd based on its own, which basically encapsulates the api operations of containers and mirrors.

Maybe some friends have also seen crictl, a command-line tool. In fact, this is the CLI defined by the K8s community according to the CRI specification. The scope of use is similar to the docker command, but it can be applied to all container runtimes that comply with the CRI specification.

Mirror operation

# 拉取镜像
> ctr image pull docker.io/library/busybox:stable

docker.io/library/busybox:stable:                                                 resolved       |++++++++++++++++++++++++++++++++++++++| 
index-sha256:b5fc1d7b2e4ea86a06b0cf88de915a2c43a99a00b6b3c0af731e5f4c07ae8eff:    done           |++++++++++++++++++++++++++++++++++++++| 
manifest-sha256:f2686aeee8a057e351a70e58d19ad530e4a4cd16e66eab6932d028153b74c96b: done           |++++++++++++++++++++++++++++++++++++++| 
config-sha256:d9d6c2bcb75096ffcf2c389eb491d2bc3d5b9f41b6a6de35f4cc9e3f2057c12e:   done           |++++++++++++++++++++++++++++++++++++++| 
layer-sha256:3f18b27a912188108c8590684206bd9da7d81bbfd0e8325f3ef0af3234b4c257:    done           |++++++++++++++++++++++++++++++++++++++| 
elapsed: 6.5 s                                                                    total:  3.5 Ki (544.0 B/s)                     
unpacking linux/arm64/v8 sha256:b5fc1d7b2e4ea86a06b0cf88de915a2c43a99a00b6b3c0af731e5f4c07ae8eff...
done

# 查询镜像
> ctr image list
# 镜像挂载到主机
> ctr image mount docker.io/library/busybox:stable /mnt
# 其他
> ctr image -h

When pulling the image, you need to enter the full address of the image, if the image is in the docker hub, it is docker.io/library/xxx

Operate the container

# 创建容器 
ctr c create docker.io/library/busybox:stable test /bin/bash -c sleep 1000

After executing the command, containerd only the container is initialized, e.g. dispensing namespace, rootfs and container configuration, and not really started the container, this initialization container through the concept Task presence using ctr task start -d test run vessel, i.e., running in a container /bin/bash -c sleep 1000 Command, of course, can also be used directly

# 直接创建并运行容器
ctr c run docker.io/library/busybox:stable test /bin/bash -c sleep 1000

When operating the container at runtime, all operations are performed through tasks, such as suspending the container ctr task pause xxx , entering the container ctr task exec --exec-id 0 -t test sh , viewing the process ctr task ps test in the container, and obtaining the container statistics ctr task metrics test

Namespaces

There is the concept of namespace in K8s, as well as in containerd, and the container started by default is in default. If the container is started through docker, it is in moby, and the container started by K8s using containerd is placed in the namespace of k8s.io.

Welcome everyone to pay attention to my official account, exchange ideas, and communicate a lot~