Containerd 入门实战

上一篇文章中咱们八卦了一下 containerd 的前世今生，以及在以后云原生生态中的地位（不小心鸽了这么久，小弟深感羞愧，现附上一篇文章的链接~）。那么本篇文章就来看看怎么应用 containerd 吧！

装置部署

安装包下载

containerd 提供了两种压缩包，一种是 containerd-${version}-${os}-${arch}.tar.gz，这个压缩包中仅蕴含了 containerd 相干的二进制文件；另外一个是cri-containerd-cni-${version}-${os}-${arch}.tar.gz，这外面是一个比拟全的压缩包，除了 containerd 相干的二进制，还蕴含了 runc（containerd 运行所依赖的底层容器运行时）以及相干命令的二进制（比方 ctr），如果作为 K8s 的容器运行时，倡议间接抉择第二种压缩包。压缩包地址都在 arm ci 记录。目前我的树莓派上，因为装置部署了依赖 containerd 的 K3s，间接的部署了 arm 架构的 containerd。

下载之后解压缩、配置环境变量，就能够应用 cri 命令查看 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

配置相干

containerd 的配置文件默认在/etc/containerd/config.toml，也能够应用命令 containerd config default > /etc/containerd/config.toml 生成一个默认的配置文件。最简略配置文件如下：

subreaper = true
oom_score = -999

[debug]
        level = "debug"

[metrics]
        address = "127.0.0.1:1338"

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

启动 containerd

linux 零碎中能够间接应用 systemd 启动守护过程，systemd 配置文件也在压缩包中：

[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

启动之后，就能够应用命令 systemctl status containerd 查看运行状态了。

下面的配置文件中，有 Delegate 的参数，设置为 yes 的意思是，零碎容许 Containerd 创立 Cgroups，并将 containerd 主过程创立的子过程（也就是容器过程）退出到本人的 Cgroups 中。否则容器过程将被 systemd 挪动到本人的 cgroups 中，containerd 主过程则无奈读取到子过程的资源状况。

此外还有一个 KillMode，设置为 process 意味着如果 containerd 主过程退出或被杀死时，不会影响其创立的子过程，从而做到了 containerd 与 容器是互不影响的。

存储

与 docker 一样，containerd 将容器相干的数据长久化在 /var/lib/containerd/中（docker 默认在 /var/lib/docker/），但存储的数据却天壤之别。containerd 的目录中全副寄存的是插件数据（与 containerd 架构图中，所有皆为插件的理念雷同），这外面包含了插件的 Snapshots、元数据等。其中 io.containerd.runtime.v1.linux 目录下则是保留了 containerd shim 的 log

.
├── 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 指令应用

启动了 containerd 的主过程之后，咱们就能够欢快的运行容器了。ctr 是 containerd 根据本身开发的命令行工具，对容器和镜像的 api 操作进行了根本封装。

兴许有小伙伴也看到过 crictl 这个命令行工具，其实这个是 K8s 社区依据 CRI 标准所定义的 CLI，应用领域相似于 docker 命令，但能够利用于所有合乎 CRI 标准的容器运行时。

对镜像操作

# 拉取镜像
> 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

拉取镜像时，须要输出镜像的齐全地址，如果镜像在 docker hub 中，则为 docker.io/library/xxx

对容器操作

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

执行上述命令后，containerd 仅仅对容器进行了初始化，例如调配 namespace，rootfs 和容器配置，并没有真正启动容器，这个初始化的容器通过 Task 的概念存在，应用 ctr task start -d test 运行容器，即在容器中运行了 /bin/bash -c sleep 1000命令，当然也能够间接应用

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

对运行时的容器进行操作时，均通过 task 进行操作，如暂停容器 ctr task pause xxx，进入容器 ctr task exec --exec-id 0 -t test sh, 查看容器内过程 ctr task ps test，获取容器的统计信息ctr task metrics test

命名空间

K8s 中存在 namespace 的概念，containerd 中也有，默认启动的容器在 default 中。如果通过 docker 启动容器，则在 moby 中，而 K8s 应用 containerd 启动的容器放在了 k8s.io 的 namespace 中。

欢送大家关注我的公众号，替换思维，多多交换~