containerd中文翻译系列(三) 操作和管理containerd

containerd 是一个可在任何系统上运行的简单守护进程。
它提供了一个带有旋钮的最小配置，用于配置守护进程和必要时使用的插件。

名称:
   containerd -
                    __        _                     __
  _________  ____  / /_____ _(_)___  ___  _________/ /
 / ___/ __ \/ __ \/ __/ __ `/ / __ \/ _ \/ ___/ __  /
/ /__/ /_/ / / / / /_/ /_/ / / / / /  __/ /  / /_/ /
\___/\____/_/ /_/\__/\__,_/_/_/ /_/\___/_/   \__,_/

高性能容器运行时


用法:
   containerd [global options] command [command options] [arguments...]

版本:
   v2.0.0-beta.0

说明

containerd 是一种高性能容器运行时，其守护进程可通过使用此命令启动。如果没有指定*config*、*publish*、*oci-hook*或*help*命令，**containerd**命令的默认操作是启动容器运行时的守护进程。命令，**containerd** 命令的默认操作是在前台启动
containerd守护进程。

如果未指定TOML配置或默认文件目录没有TOML配置文件，则使用默认配置。
*containerd config* 命令可用于生成 containerd 的默认配置。该命令的输出
可用作自定义配置，并根据需要进行修改。

命令：
   config   配置信息
   publish  向容器发布事件
   oci-hook 为 OCI 运行时钩子提供基础，以便注入参数。
   help, h 显示命令列表或某个命令的帮助

全局选项：
   --config value, -c value 配置文件的路径(默认："/etc/containerd/config.toml")。
   --log-level value, -l value 设置日志记录级别 [trace, debug, info, warn, error, fatal, panic] (默认值："/etc/containerd/config.toml")。
   --address value, -a value containerd的GRPC服务器地址
   --root value containerd根目录
   --state value containerd状态目录
   --help, -h 显示帮助
   --version, -v 打印版本

虽然可以通过 CLI 标志设置一些守护进程级别的选项，但 containerd 的大部分配置都保存在配置文件中。
配置文件的默认路径位于 /etc/containerd/config.toml。
启动守护进程时，可以通过 --config,-c标志更改该路径。

systemd

如果使用 systemd 作为启动系统（大多数现代 Linux 操作系统都使用 systemd），则需要对服务文件进行一些修改。

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

[Service]
ExecStartPre=-/sbin/modprobe overlay
ExecStart=/usr/local/bin/containerd
Delegate=yes
KillMode=process

[Install]
WantedBy=multi-user.target

Delegate=yes和 KillMode=process是你需要在[Service]部分做出的两个最重要的更改。

Delegate允许 containerd 及其运行时管理它创建的容器的cgroup。
如果不设置该选项，systemd 会尝试将进程移入它自己的 cgroup，从而导致containerd 及其运行时无法正确计算容器的资源使用情况。

KillMode用于处理containerd的关闭。
默认情况下，systemd 会在其命名的cgroup中查找并杀死它所知道的服务的所有进程。
这不是我们想要的。
作为操作人员，我们希望能够升级 containerd，并允许现有容器不间断地继续运行。
将 KillMode 设置为 process 可以确保 systemd 只杀死 containerd 守护进程，而不杀死任何子进程，如shim和容器。

下面的 systemd-run 命令以类似方式启动 containerd：

sudo systemd-run -p Delegate=yes -p KillMode=process /usr/local/bin/containerd

基本配置

在 containerd 配置文件中，你可以找到持久和运行时存储位置的设置，以及各种 API 的 grpc、debug和metrics地址。

有几个设置对运行非常重要。
第一个设置是 oom_score 。 由于 containerd 将管理多个容器，我们需要确保在 containerd 守护进程出现内存不足的情况之前杀死容器。
我们也不想让 containerd长生不死，但我们想把它的得分降低到其他系统守护进程的水平。

containerd 还通过 /v1/metrics 下的 Prometheus 指标格式导出它自己的指标和容器级指标。
目前，Prometheus 只支持 TCP 端点，因此，metrics 地址应该是 Prometheus 基础架构可以从中抓取指标的 TCP 地址。

containerd 在主机系统上还有两个不同的存储位置。
一个用于存储持久数据，另一个用于存储运行时状态。

root将用于存储containerd 的任何类型的持久性数据。
快照、内容、容器和映像的元数据以及任何插件数据都将保存在这个位置。
根目录还为 containerd 加载的插件命名空间化。
每个插件都有自己的目录来存储数据。
实际上，containerd 本身并不需要存储任何持久性数据，它的功能来自于加载的插件。

/var/lib/containerd/
├── io.containerd.content.v1.content
│   ├── blobs
│   └── ingest
├── io.containerd.metadata.v1.bolt
│   └── meta.db
├── io.containerd.runtime.v2.task
│   ├── default
│   └── example
├── io.containerd.snapshotter.v1.btrfs
└── io.containerd.snapshotter.v1.overlayfs
    ├── metadata.db
    └── snapshots

state 将用于存储任何类型的短暂数据。
套接字、pids、运行时状态、挂载点和其他在重启时不能持久存在的插件数据都存储在此位置。

/run/containerd
├── containerd.sock
├── debug.sock
├── io.containerd.runtime.v2.task
│   └── default
│       └── redis
│           ├── config.json
│           ├── init.pid
│           ├── log.json
│           └── rootfs
│               ├── bin
│               ├── data
│               ├── dev
│               ├── etc
│               ├── home
│               ├── lib
│               ├── media
│               ├── mnt
│               ├── proc
│               ├── root
│               ├── run
│               ├── sbin
│               ├── srv
│               ├── sys
│               ├── tmp
│               ├── usr
│               └── var
└── runc
    └── default
        └── redis
            └── state.json

root和 state目录都是为插件命名空间化的。
这两个目录是 containerd 及其插件的实现细节。
它们不应被篡改，因为损坏和 bug 可能会发生。
众所周知，当 containerd 和/或其插件试图清理资源时，读取或观察这些目录中变化的外部应用程序会导致 EBUSY 和陈旧的文件句柄。

version = 2

# persistent data location
root = "/var/lib/containerd"
# runtime state information
state = "/run/containerd"
# set containerd's OOM score
oom_score = -999

# grpc configuration
[grpc]
  address = "/run/containerd/containerd.sock"
  # socket uid
  uid = 0
  # socket gid
  gid = 0

# debug configuration
[debug]
  address = "/run/containerd/debug.sock"
  # socket uid
  uid = 0
  # socket gid
  gid = 0
  # debug level
  level = "info"

# metrics configuration
[metrics]
  # tcp address!
  address = "127.0.0.1:1234"

插件配置

说到底，containerd 的核心非常小。
真正的功能来自插件。
从快照器、运行时到内容都是在运行时注册的插件。
由于这些插件千差万别，我们需要一种为插件提供类型安全配置的方法。
我们能做到这一点的唯一方法是通过配置文件，而不是 CLI 标志。

在配置文件中，您可以通过"[plugins.]"部分为您使用的插件集指定插件级选项。
你必须阅读插件的具体文档，才能找到你的插件所接受的选项。

请参阅 containerd 的插件文档

Bolt 元数据插件

bolt 元数据插件允许配置命名空间之间的内容共享策略。

默认模式为 shared，一旦 blob 被拉入任何命名空间，它将在所有命名空间中可用。
如果写入器使用后端已存在的 Expected摘要打开，blob 将被拉入命名空间。

另一种模式是 isolated模式，要求客户端在将 Blob 添加到命名空间之前，通过向摄取(内容引入或引用)提供所有内容来证明自己有访问内容的权限。

这两种模式都共享后备数据，而shared模式会减少整个命名空间的总带宽，但代价是只需知道摘要就可以访问任何 Blob。

默认模式为 shared。虽然这是最理想的策略，但也可以通过以下配置更改为 isolated模式：

version = 2

[plugins."io.containerd.metadata.v1.bolt"]
	content_sharing_policy = "isolated"

在 "isolated "模式下，还可以通过在特定命名空间中添加标签 containerd.io/namespace.shareable=true，只共享该命名空间的内容。
这样，即使内容共享策略设置为 isolated，其 blobs 也可以在所有其他命名空间中使用。
如果将标签值设置为 true以外的任何其他值，命名空间的内容将不会被共享。