Linux containerd 的 config.toml plugins 与 snapshotter overlaybd 选择

plugins.”io.containerd.grpc.v1.cri”.containerd.snapshotter 指定 cri 插件使用的快照驱动名（如 overlaybd），但该驱动必须已在顶层 plugins.”io.containerd.snapshotter.v1.overlaybd” 显式注册且可执行，否则会降级为 overlayfs。

containerd config.toml 里 plugins.”io.containerd.grpc.v1.cri”.containerd.snapshotter 是干啥的

这个配置项决定 CRI 插件在拉取镜像、启动容器时用哪个快照驱动来管理镜像层和容器读写层。它不控制底层存储引擎（比如 overlayfs 或 overlaybd），而是指定 containerd 调用哪个 snapshotter 插件来对接该引擎。

常见误区是以为设成 overlaybd 就自动启用 overlaybd —— 实际上，overlaybd 必须先作为独立插件注册进 containerd，再被 CRI 插件引用。否则 containerd 启动会报错：failed to load plugin io.containerd.grpc.v1.cri: unknown snapshotter: overlaybd

• 必须确保 overlaybd 的二进制（如 overlaybd-snapshotter）已安装且可执行
• 必须在 plugins 根层级显式声明 overlaybd 插件，不能只在 CRI 下配
• snapshotter 值只是名字，最终行为取决于同名插件是否真实加载成功

overlaybd snapshotter 插件注册要写在哪一级 config.toml

必须写在顶层 plugins 下，路径是 plugins."io.containerd.snapshotter.v1.overlaybd"，不是嵌套在 CRI 插件内部。containerd 启动时按顺序加载所有顶层插件，CRI 插件后续才能引用它们。

典型错误配置是把 overlaybd 配置块塞进 plugins."io.containerd.grpc.v1.cri" 里，这样 containerd 根本不会识别它为 snapshotter 插件，只会忽略或报解析错误。

• 正确位置：plugins."io.containerd.snapshotter.v1.overlaybd"
• 必须包含 bin 字段，指向 overlaybd-snapshotter 可执行文件绝对路径
• 推荐加 root_path 显式指定工作目录，避免默认路径权限或磁盘空间问题
• 如果用了 overlaybd 的 remote layer 功能，config_path 指向 JSON 配置文件也得存在且可读

为什么设了 overlaybd 还 fallback 到 overlayfs

containerd 不会“静默降级”，但 CRI 插件在初始化 snapshotter 时若发现目标插件未就绪（进程未启动、socket 未监听、健康检查失败），就会跳过并尝试下一个备选（通常是 overlayfs）。现象是 crictl info 显示 snapshotter: overlayfs，即使 config.toml 写了 overlaybd。

• 检查 systemctl status containerd 日志，搜索 overlaybd 和 failed to start
• 确认 overlaybd-snapshotter 进程是否运行：ps aux | grep overlaybd-snapshotter
• 手动调用 overlaybd-snapshotter --help 看是否报动态库缺失（如 libzstd.so.1）
• CRI 插件默认只等 snapshotter socket 出现 5 秒，超时即放弃 —— 若 overlaybd 启动慢，需调大 plugins."io.containerd.grpc.v1.cri".containerd.default_runtime_name 对应 runtime 的 options 中的 snapshotter 初始化超时（但通常应优化 overlaybd 启动速度）

overlaybd 和 overlayfs 共存时怎么让特定 Pod 用 overlaybd

不能靠 Pod annotation 或 runtimeClass 名字直接切换 snapshotter —— containerd CRI 插件目前只支持全局指定一个 snapshotter。所谓“共存”实际是通过 runtimeClass + 自定义 runtime 实现：把 overlaybd 绑定到某个 runtime，再让 Pod 显式声明 runtimeClassName: overlaybd-runtime。

• 在 config.toml 中定义两个 runtime：default（用 overlayfs）和 overlaybd-runtime（用 overlaybd）
• 每个 runtime 的 options 里指定 snapshotter 字段，值为已注册的插件名（如 "overlaybd"）
• 注意：同一 containerd 实例下，不同 runtime 可以用不同 snapshotter，但每个 runtime 只能用一个
• Pod 必须带 runtimeClassName，否则走 default runtime，无视 CRI 插件级的 snapshotter 设置

这一步容易漏掉 runtimeClass 对象本身没创建，或者 Pod 所在 namespace 没开启 RuntimeClass feature gate。