Containerd中Privileged Pod的sysfs挂载问题解析

在Kubernetes环境中使用containerd作为容器运行时，用户可能会遇到一个关于特权容器中sysfs文件系统挂载权限的问题。本文将深入分析该问题的现象、原因以及解决方案。

问题现象

当用户在Kubernetes 1.23.7及以上版本环境中，使用containerd 1.6.21或1.7.24作为容器运行时，创建带有特权模式(privileged)和安全上下文(securityContext)配置的Pod时，发现容器内部的sysfs文件系统被挂载为只读(ro)模式，而非预期的读写(rw)模式。

具体表现为：

• 容器配置中明确设置了privileged: true
• crictl inspect显示sysfs的挂载选项包含"rw"
• 但实际容器内mount命令显示sysfs为"ro,nosuid,nodev,noexec,relatime"

技术背景

sysfs是Linux内核提供的一个虚拟文件系统，它将内核数据结构、设备和驱动程序信息以文件的形式呈现给用户空间。在容器环境中，正确挂载sysfs对于许多系统级操作至关重要，特别是在特权容器中。

在传统Docker环境中，特权容器的sysfs通常会正确挂载为读写模式。然而在containerd实现中，由于安全模型和挂载逻辑的差异，导致了这一不一致行为。

问题原因

经过分析，这个问题主要源于containerd在挂载sysfs时的处理逻辑：

1. containerd的CRI插件在处理特权容器时，虽然设置了rw挂载选项
2. 但在实际挂载过程中，某些安全机制(如SELinux)会覆盖这些选项
3. 特别是当同时配置了seLinuxOptions时，会导致最终的挂载权限被降级

解决方案

对于遇到此问题的用户，可以考虑以下几种解决方案：

1. 升级containerd版本：该问题在containerd 2.0.x版本中已得到修复，建议升级到最新稳定版

2. 手动重新挂载：在容器启动命令中加入重新挂载指令

command: ["sh", "-c", "mount -o remount,rw /sys && tail -f /dev/null"]

3. 显式挂载sysfs卷：在Pod配置中明确指定sysfs挂载

volumeMounts:
- name: sysfs
  mountPath: /sys
volumes:
- name: sysfs
  hostPath:
    path: /sys
    type: Directory

不同运行时的对比测试

通过对不同容器运行时的测试比较，我们发现：

• CRI-O和Docker运行时在特权容器中都能正确保持sysfs的读写权限
• 只有containerd在仅配置privileged时会出现sysfs只读的情况
• 当同时配置volume挂载时，所有运行时都能正确保持读写权限

最佳实践建议

对于生产环境，我们建议：

1. 优先考虑升级containerd到已修复该问题的版本
2. 如果暂时无法升级，可采用手动重新挂载的方案
3. 对于需要频繁访问sysfs的特权容器，建议显式配置volume挂载
4. 仔细评估特权容器的安全风险，仅在必要时使用privileged模式

这个问题展示了容器运行时实现细节对应用行为的影响，也提醒我们在跨不同运行时环境时需要进行充分的兼容性测试。