关于云原生-cloud-native: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

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

启动了 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 中。

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

关于云原生-cloud-native:Containerd-入门实战

Containerd 入门实战

装置部署

安装包下载

配置相干

启动 containerd

存储

ctr 指令应用

对镜像操作

对容器操作

命名空间