NVIDIA k8s-device-plugin中MPS共享GPU访问问题解析

问题背景

在使用NVIDIA k8s-device-plugin实现多进程共享(MPS)GPU资源时，部分用户可能会遇到MPS控制守护进程启动失败的问题。典型错误表现为SELinux权限拒绝或CUDA MPS控制命令缺失。

核心错误分析

从实际案例中，我们观察到两种主要的错误模式：

1. SELinux权限问题：当MPS守护进程尝试设置SELinux上下文时，出现lsetxattr /mps/nvidia.com/gpu/pipe: permission denied错误。这表明容器运行环境启用了SELinux安全策略，但容器缺乏足够的权限来修改文件系统属性。

2. CUDA MPS工具缺失：错误信息exec: "nvidia-cuda-mps-control": executable file not found in $PATH表明基础镜像中缺少必要的CUDA MPS控制工具。

根本原因

经过深入分析，发现问题的根源在于：

1. 操作系统镜像选择：使用Bottlerocket AMI家族时，预装的NVIDIA驱动版本为535.216.01，而Amazon Linux 2(AL2) AMI家族则提供550.127.08版本驱动。不同驱动版本对MPS的支持存在差异。

2. 容器权限配置：当节点启用SELinux时，容器需要适当的权限来操作MPS管道文件。

解决方案

针对上述问题，推荐以下解决方案：

1. 使用兼容的AMI家族：优先选择Amazon Linux 2(AL2) AMI家族，确保驱动版本兼容性。

2. 调整SELinux策略：

   • 对于必须使用SELinux的环境，可以通过修改Pod安全上下文或创建适当的SELinux策略来解决权限问题
   • 或者临时禁用SELinux（仅限测试环境）

3. 验证驱动版本：部署前检查节点标签中的nvidia.com/cuda.driver-version.full值，确保使用受支持的驱动版本。

配置建议

以下是一个经过验证的Helm配置示例，适用于MPS共享模式：

config:
  map:
    default: |-
      version: v1
      sharing:
        mps:
          resources:
            - name: nvidia.com/gpu
              replicas: 4

最佳实践

1. 环境一致性：确保测试和生产环境使用相同的AMI和驱动版本组合
2. 监控与日志：密切监控MPS守护进程日志，及时发现潜在问题
3. 渐进式部署：先在少量节点上验证MPS功能，再逐步扩大部署范围

总结

NVIDIA k8s-device-plugin的MPS功能为GPU资源共享提供了强大支持，但在实际部署中需要注意操作系统镜像选择和权限配置。通过遵循上述建议，可以显著提高部署成功率并确保稳定的运行环境。