containerd镜像卷挂载失败：erofs快照器兼容性问题

概述

在 Kubernetes 与容器运行时环境中，镜像卷是一种便捷的机制，允许将容器镜像的内容直接挂载到 Pod 的指定路径。此功能对于分发配置、证书或静态资产非常有用。然而，该功能的正确实现高度依赖于底层容器运行时的快照器（snapshotter）机制。本文档记录了一个在特定配置下使用 erofs 快照器时，containerd 无法成功挂载镜像卷的已知问题，该问题会导致 Pod 启动失败或卷内容异常，是 SRE 在配置和故障排查中需要关注的重要场景。

核心概念

镜像卷 (Image Volume)：一种 Kubernetes 卷类型，它不依赖于预先存在的持久卷或配置映射，而是直接从指定的容器镜像中提取文件系统内容，并将其挂载到 Pod 的容器中。其核心在于利用容器运行时的能力来“挂载”一个镜像。
Erofs 快照器 (Erfs Snapshotter)：containerd 的一个快照驱动插件，用于管理容器镜像的文件系统层。它旨在利用 EROFS（可扩展只读文件系统）的特性来存储和访问容器层。在某些配置下，它可能通过 overlay 机制（如 mount 选项所示）来实现层的合并。
Containerd CRI 插件：负责与 Kubernetes kubelet 通过 CRI (Container Runtime Interface) 通信的 containerd 组件，处理 Pod 和容器的生命周期管理，包括卷的挂载。io.containerd.cri.v1.images 插件配置了用于镜像管理的快照器。
no such device 错误：通常是一个低级的系统错误，在 Linux 内核的文件系统或块设备层产生。在此上下文中，它表明在尝试执行某个特定设备或文件系统相关的操作时，内核找不到所需的设备或不支持该操作。

实践

问题复现与症状

环境：Kubernetes 1.36.1，containerd v2.3.1（或 v2.2.4），配置使用 erofs 快照器。

操作：部署一个包含镜像卷定义的 Pod，例如：

volumes:
- name: volume
  image:
    reference: registry.k8s.io/e2e-test-images/kitten:1.7
    pullPolicy: Always

失败现象：
- Pod 事件显示错误：Error: failed to mount image volume: ... err: no such device。
- 即使 Pod 运行，挂载的卷路径（如 /volume）内容为空或与宿主机根目录结构相似，而非预期的镜像文件内容。
- 对比验证：将 config.toml 中 snapshotter 的值从 erofs 改为 overlayfs，相同的镜像卷挂载操作成功，卷内文件完整可见。

根本原因分析

该问题的根本原因在于 erofs 快照器在执行镜像卷挂载操作时，其内部使用的 overlay 挂载方式与内核或系统环境不兼容。具体表现为：

containerd 在尝试挂载镜像卷时，会为镜像创建一个临时的、基于快照的挂载点。日志显示其尝试使用 overlay 作为文件系统类型 (fstype: format/mkdir/overlay)。
此次挂载尝试失败，内核返回 no such device。这通常意味着：
- 内核未加载支持所需操作的模块（尽管在此场景下不太可能）。
- 快照器的代码路径尝试了一个在当前内核或 erofs 实现中不支持或未正确初始化的设备操作。
- 在使用 erofs 作为后端存储时，overlay 层的组合方式可能存在兼容性问题。

该问题是一个已知的兼容性缺陷，影响使用 erofs 快照器的 containerd 版本。

解决方案与规避措施

对于遇到此问题的 SRE 或平台工程师，有以下明确的应对策略：

主要规避方案（推荐）：将 containerd 配置中的快照器从 erofs 切换到 overlayfs。这是目前最稳定、验证最充分的方案。
- 修改 /etc/containerd/config.toml 中 [plugins.'io.containerd.cri.v1.images'] 下的 snapshotter 字段。
- 修改后需重启 containerd 服务：sudo systemctl restart containerd。
等待上游修复：关注 GitHub issue #13534，等待 containerd 官方在后续版本中修复 erofs 快照器与此功能的兼容性问题。在修复发布前，应持续使用 overlayfs。
评估业务影响：如果业务强依赖 erofs 的特定性能或存储特性，则需评估是否可以暂时放弃使用镜像卷功能，改用其他方式（如 ConfigMap、Secret 或初始化容器拷贝文件）来达成目标，直至问题解决。

SRE 要点

可靠性影响：此问题直接导致使用镜像卷的 Pod 无法启动或启动后功能异常（卷内容缺失）。这在依赖此功能部署关键组件（如包含配置文件的 sidecar）时，会引发服务中断或启动延迟，影响集群的整体可靠性和部署流水线的稳定性。
可观测性：
- 关键信号：Pod 事件中的 FailedMount 或 ImageVolumeMountFailed 错误，以及 no such device 是首要的告警和排查线索。
- 日志分析：需要检查 containerd 的日志，查找与 image-volumes 和 overlay 挂载相关的详细错误信息。
- 节点检查：在节点上使用 crictl 或手动执行挂载命令，可以复现和验证文件系统层面的问题。
事件响应与故障排查路径：
1. 确认失败 Pod 的错误事件，识别 ImageVolumeMountFailed。
2. 检查节点 containerd 配置，确认使用的 snapshotter 类型。
3. 如果是 erofs，则立即尝试修改为 overlayfs 并重启 containerd，重新部署 Pod 进行验证。
4. 同时在上游 issue 追踪修复进展，规划未来版本的升级路径。
最佳实践与反模式：
- 最佳实践：在生产环境中，对新采用的 containerd 快照器特性（如 erofs）应进行充分的兼容性测试，包括镜像卷挂载场景。在 overlayfs 验证充分的情况下，优先使用 overlayfs 作为默认快照器。
- 常见反模式：在未验证特定快照器与所有 Kubernetes 高级特性（如镜像卷）兼容性的情况下，便将其设为生产集群的默认配置。这可能导致潜在的功能性故障在关键时刻暴露。
相关指标 (SLI/SLO)：
- SLI (Service Level Indicator)：可以监控 “Pod 因卷挂载失败的启动成功率”。具体到镜像卷，可定义 image_volume_mount_success_rate 指标。
- SLO (Service Level Objective)：应确保在特定配置（如使用 erofs 快照器的节点）下，该 SLI 满足预定的可靠性目标（如 99.9%）。当监控到失败率升高时，需触发故障排查流程。
- 此问题凸显了在配置变更（如切换快照器）后，进行渐进式发布和全面功能验证的重要性。