Containerd Gets started

We first met Containerd in our last article. We talked a little bit about Containerd’s past and present life, and its place in the current cloud ecosystem. This article will take a look at how to use Containerd.

Install the deployment

Download the installation package

Containerd -${version}-${OS}-${arch}.tar.gz contains only containerd binary files. Ci-containerd-cni -${version}-${OS}-${arch}.tar.gz -${arch}.tar. It also contains runC (the underlying container runtime on which containerd runs) and binaries of related commands (such as CTR). If it runs as a K8s container, it is recommended to choose the second package directly. The address of the compressed package is in github release.

As a reminder, the github release of ContainerD only supports THE AMD64 architecture (x86). The team only maintains the ARM CI process on OpenLab: ARM CI record. Currently, ON my raspberry PI, I’m indirectly deploying containerD with the ARM architecture by installing K3s that rely on ContainerD.

After you download it, unzip it and configure the environment variables to view the version of Containerd using the cri command

$ export PATH=$PATH:/usr/local/bin:/usr/local/ sbin $CTR version Client: version: 1.3.7 Revision: 8 fba4e9a7d01810a393d5d25a3621dc101981175 Server: version: 1.3.7 Revision: 8 fba4e9a7d01810a393d5d25a3621dc101981175 UUID: c05a8353 - fe - af5b58f32b5b d52c - 44 CD - 88Copy the code

Configuration related

Containerd default configuration file in/etc/containerd/config toml, 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
Copy the code

Start the containerd

In Linux, you can start the systemd daemon directly. The systemd configuration file is also included in the 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.targetCopy the code

Once started, you can run the systemctl status containerd command to check whether it is containerd.

The Delegate parameter is set to yes, which means that Containerd is allowed to create Cgroups and add child processes created by Containerd’s main process to its 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 processes.

There is also a KillMode set to Process, which means that if the main Containerd process quits or is killed, it does not affect the child processes it creates, so that containerd is not affected by the container.

storage

Like Docker, containerd persists container-specific data in /var/lib/containerd/ (docker defaults to /var/lib/docker-/), but stores very different data. The Containerd directory contains all the plug-ins in it. It calls all the Snapshots and metadata in the containerd architecture diagram. The IO. Containerd. Runtime. V1. Linux directory is preserved the containerd shim log

. ├ ─ ─ IO. Containerd. Content. v1. The 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 └ ─ ─ tmpmountsCopy the code

Use the CTR command

Once containerd’s main process is started, we can happily run the container. CTR is a command-line tool developed by Containerd to encapsulate container and image API operations.

Crictl is a command-line tool defined by the K8s community according to the CRI specification. The use category is similar to the Docker command, but it can be applied to all container runtimes that comply with the CRI specification.

Mirror operation

# pull mirror
> 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

# query mirror
> ctr image list
Mount the image to the host
> ctr image mount docker.io/library/busybox:stable /mnt
# other
> ctr image -h
Copy the code

IO /library/ XXX if the image is in the Docker hub

Operation on container

Create a container
ctr c create docker.io/library/busybox:stable test /bin/bash -c sleep 1000
Copy the code

After executing the above command, containerd only initializes the container, such as assigning namespaces, rootfs, and container configuration. It does not actually start the container. The initialized container exists through the concept of Task. Run CTR task start -d test, that is, run /bin/bash -c sleep 1000 in the container, or run CTR task start -d test directly

Create and run the container directly
ctr c run docker.io/library/busybox:stable test /bin/bash -c sleep 1000
Copy the code

Operations on running containers are performed by task, for example, CTR task pause XXX, Run the CTR task exec –exec-id 0 -t test sh command to view the process CTR task ps test and obtain the statistics of the container CTR task metrics test

The namespace

Namespace is used in K8s and containerd. The default container is in default. If the container is started with docker, it is in moBY, while K8s uses Containerd to start containers in namespace of K8s. IO.

Welcome to pay attention to my public number, exchange ideas, a lot of communication ~