containerd安装后必做的5项配置：从镜像加速到systemd驱动

containerd安装后必做的5项配置：从镜像加速到systemd驱动

刚把containerd装好，看着服务跑起来，是不是觉得万事大吉了？别急，这就像刚买回一台性能车，不调校一下悬挂、不刷个一阶程序，你永远体会不到它真正的实力。containerd的默认配置是为“能跑”设计的，但离“跑得好”、“跑得稳”还差得远。尤其是在生产环境或者准备接入Kubernetes集群时，几个关键的配置项没动，后续的麻烦会接踵而至——镜像拉取慢如蜗牛、容器cgroup管理混乱、日志淹没在噪音里。这篇文章，我们就来聊聊containerd安装完成后，那些真正影响性能和稳定性的、必须动手调整的五项核心配置。无论你是单机使用还是为Kubernetes做准备，这些调整都能让你的容器运行时环境脱胎换骨。

1. 镜像加速器配置：告别漫长的等待

在国内网络环境下，从Docker Hub直接拉取镜像的体验，常常让人有砸键盘的冲动。默认配置下，containerd会直连境外的公共镜像仓库，速度慢不说，还经常因为网络波动而失败。配置镜像加速器，是提升容器部署效率的第一步，也是最立竿见影的一步。

containerd的镜像仓库配置集中在/etc/containerd/config.toml文件的[plugins."io.containerd.grpc.v1.cri".registry]部分。我们需要在这里为常用的镜像仓库域名（如docker.io、gcr.io、quay.io）配置国内的镜像加速器端点。

一个典型的配置片段如下所示。这里我们以配置docker.io（即Docker Hub）的阿里云加速器为例：

[plugins."io.containerd.grpc.v1.cri".registry.mirrors] [plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"] endpoint = ["https://<your-mirror-id>.mirror.aliyuncs.com"]

注意：请将<your-mirror-id>替换为你从阿里云容器镜像服务控制台获取的实际加速器地址。不同服务商（如腾讯云、华为云、中科大）的地址格式不同，但配置结构一致。

仅仅配置镜像拉取的“高速公路”还不够，有时我们还需要为私有仓库或特定仓库配置认证信息。这在企业内网部署或使用需要登录的镜像服务时至关重要。config.toml中的configs部分就是用来干这个的。

[plugins."io.containerd.grpc.v1.cri".registry.configs] [plugins."io.containerd.grpc.v1.cri".registry.configs."harbor.mycompany.com".auth] username = "robot$myproject" password = "your_secure_token_here"

配置完成后，务必重启containerd服务使配置生效：sudo systemctl restart containerd。之后，你可以通过crictl pull或ctr images pull命令测试拉取镜像的速度，感受从“绿皮火车”到“高铁”的飞跃。

2. 启用systemd cgroup驱动：与Kubernetes和谐共处

如果你计划将这台主机作为Kubernetes的节点，那么启用systemd cgroup驱动是必须完成的操作。Kubernetes自1.21版本后，其默认的kubelet cgroup驱动已从cgroupfs切换为systemd。如果containerd的cgroup驱动与kubelet不一致，节点将无法正常启动Pod，并报出failed to create the containerd task之类的错误。

containerd的默认配置中，SystemdCgroup选项是false。我们需要将其修改为true。这个配置项同样位于/etc/containerd/config.toml中。

最直接的方法是使用文本编辑器（如vim或nano）打开配置文件，找到[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]部分，将SystemdCgroup的值改为true。

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options] SystemdCgroup = true

如果你习惯命令行操作，也可以使用sed命令快速完成修改：

sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml

修改后，同样需要重启containerd服务。为了验证配置是否生效，可以运行一个测试容器，然后检查其cgroup路径。如果路径中包含了system.slice，则说明systemd驱动已启用。

sudo ctr run -d --rm docker.io/library/alpine:latest test-sleep sleep 3600 # 获取容器进程ID PID=$(sudo ctr task ls | grep test-sleep | awk '{print $2}') # 查看cgroup信息 sudo cat /proc/$PID/cgroup | grep memory # 输出应类似：.../system.slice/containerd-...

3. 调整日志级别与输出：从噪音中捕捉信号

默认情况下，containerd的日志级别是info。这在日常运行中没问题，但一旦出现问题需要排查，info级别的日志可能信息量不足。另一方面，如果日志过于详细（比如debug级别），又会产生海量数据，淹没真正有用的信息，并可能影响磁盘I/O。因此，根据环境需求调整日志级别是一项重要的调优工作。

日志配置在config.toml的[debug]部分。level字段定义了日志的详细程度，可选值包括debug、info、warn、error、fatal、panic。

[debug] level = "info" # 可改为 "debug" 或 "warn" address = "/run/containerd/debug.sock"

除了级别，日志的输出格式和目的地也值得关注。containerd默认将日志输出到系统日志（通过systemd-journald）。对于生产环境，我们可能希望将日志集中收集到特定的文件或日志管理系统中。这可以通过配置log部分实现，但更常见的做法是配合systemd的日志转发功能，或者使用containerd的logging插件（如果编译时包含）。

一个实用的技巧是，在调试特定问题时，可以临时将日志级别调整为debug，并配合journalctl命令进行实时跟踪：

# 临时修改配置并重启 sudo sed -i 's/level = "info"/level = "debug"/' /etc/containerd/config.toml sudo systemctl restart containerd # 实时查看containerd的详细日志 sudo journalctl -u containerd -f # 问题解决后，记得将级别改回，避免磁盘被日志塞满 sudo sed -i 's/level = "debug"/level = "info"/' /etc/containerd/config.toml sudo systemctl restart containerd

4. 存储与运行时配置：性能与稳定的基石

存储配置决定了容器镜像和容器可写层的存放位置与组织形式，直接影响I/O性能和磁盘空间利用率。containerd默认使用overlayfs作为存储驱动，这对于大多数使用ext4或xfs文件系统的Linux发行版来说是最佳选择。

关键配置在[plugins."io.containerd.grpc.v1.cri".containerd]部分。snapshotter字段定义了存储驱动，root和state字段定义了相关数据的存储路径。

[plugins."io.containerd.grpc.v1.cri".containerd] snapshotter = "overlayfs" default_runtime_name = "runc" [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc] runtime_type = "io.containerd.runc.v2" [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options] SystemdCgroup = true

对于高性能或特殊需求场景，你可能需要考虑：

• 更改数据根目录：默认的/var/lib/containerd可能位于系统盘。如果系统盘空间紧张，可以将root路径指向更大容量的数据盘。
• 使用高性能存储驱动：在btrfs或zfs文件系统上，可以启用对应的snapshotter以获得更好的快照性能和数据去重能力。但这需要文件系统本身的支持和额外的配置。

另一个容易被忽略但至关重要的配置是沙箱（pause）镜像。在Kubernetes中，每个Pod都会先启动一个特殊的“pause”容器来持有网络命名空间。containerd需要知道从哪里拉取这个镜像。

[plugins."io.containerd.grpc.v1.cri"] sandbox_image = "registry.k8s.io/pause:3.9"

提示：对于国内用户，直接拉取registry.k8s.io的镜像也可能很慢。一个常见的做法是先将pause镜像从国内源（如阿里云镜像仓库）拉取到本地，然后修改sandbox_image为本地镜像的标签，或者配置对应的镜像加速器。

5. 网络与CNI插件集成：让容器互联互通

containerd本身是一个容器运行时，不直接管理网络。容器的网络功能需要通过CNI（Container Network Interface）插件来实现。即使你不使用Kubernetes，只是单纯用containerd运行容器，也需要正确配置CNI，否则容器将只有loopback网络，无法与外界通信。

首先，确保CNI插件二进制文件已经安装在/opt/cni/bin/目录下。你可以从项目发布页下载并解压。

# 下载CNI插件（以v1.3.0为例） CNI_VERSION="v1.3.0" sudo mkdir -p /opt/cni/bin curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-amd64-${CNI_VERSION}.tgz" | sudo tar -C /opt/cni/bin -xz

接着，需要准备CNI的配置文件。默认的配置文件路径是/etc/cni/net.d/。一个最简单的、用于测试的桥接网络配置如下，将其保存为/etc/cni/net.d/10-mynet.conf：

{ "cniVersion": "0.4.0", "name": "mynet", "type": "bridge", "bridge": "cni0", "isGateway": true, "ipMasq": true, "ipam": { "type": "host-local", "subnet": "10.22.0.0/16", "routes": [ { "dst": "0.0.0.0/0" } ] } }

containerd的CRI插件会自动发现并使用这个目录下的配置。配置完成后，启动一个容器并检查其网络，应该能看到它获取到了10.22.0.0/16网段的IP，并且可以访问外网。

对于生产环境，特别是Kubernetes集群，网络配置要复杂得多，通常会使用Calico、Cilium、Flannel等成熟的CNI插件。这些插件会提供自己的配置文件并覆盖默认配置。此时，你需要确保containerd的CNI配置目录路径正确，并且有足够的权限被containerd进程读取。

最后，别忘了安全加固。虽然超出了基础配置的范围，但在生产环境中，考虑启用AppArmor或SELinux的containerd配置文件，限制容器的默认能力（default_capabilities），以及为不同的运行时（如kata-containers、gVisor）配置不同的runtime_handler，都是构建稳健容器平台的重要步骤。这些配置都可以在config.toml的runtimes部分找到对应的选项。