Bottlerocket OS中DCGM无法在GPU节点上运行的问题分析与解决方案

问题背景

Bottlerocket OS是一款专为容器化工作负载设计的轻量级操作系统。在1.20.0版本的aws-k8s-1.29-nvidia变体中，用户发现NVIDIA的DCGM（Data Center GPU Manager）工具无法正常运行，导致无法监控GPU节点的性能指标。

问题现象

当用户在基于Bottlerocket k8s nvidia AMI的GPU节点上部署DCGM Daemonset时，会遇到初始化NVML失败的错误。错误信息显示"Failed to initialize NVML"，表明系统无法正确识别和访问NVIDIA GPU硬件。

根本原因分析

经过技术团队深入调查，发现该问题与Bottlerocket OS的安全设计有关：

1. 安全权限限制：Bottlerocket默认对非特权容器的GPU访问进行了限制，这是出于安全考虑的设计选择。

2. NVIDIA_VISIBLE_DEVICES机制：系统修改了NVIDIA_VISIBLE_DEVICES环境变量的默认行为，使得非特权容器即使设置了NVIDIA_VISIBLE_DEVICES=all也无法访问所有GPU设备。

3. 容器运行时配置：虽然系统已经配置了NVIDIA containerd运行时，但默认的安全策略阻止了DCGM等工具的正常运行。

临时解决方案

目前可以通过以下两种方式临时解决问题：

1. 提升容器权限：为DCGM容器添加SYS_ADMIN能力

   securityContext:
     capabilities:
       add: ["SYS_ADMIN"]
   

   这种方法不需要完全特权模式(privileged: true)，相对更安全。

2. 使用系统内置设备插件：Bottlerocket已经内置了NVIDIA设备插件作为系统服务，用户无需自行部署额外的设备插件副本，避免潜在的冲突问题。

长期解决方案

技术团队正在开发一个API来解决这个问题，主要特性包括：

1. 配置灵活性：通过设置visible-devices-envvar-when-unprivileged参数，允许用户选择是否恢复原来的行为。

2. 安全权衡：用户需要明确了解启用此功能可能带来的安全影响，特别是在多租户环境中。

3. 资源约束一致性：当前实现下，即使容器设置了资源限制，启用此功能后容器仍可能访问所有GPU，这需要特别注意。

最佳实践建议

1. 生产环境部署：

   • 优先考虑使用CAP_SYS_ADMIN方案而非完全特权模式
   • 等待官方API发布后再评估是否启用visible-devices-envvar-when-unprivileged

2. 安全注意事项：

   • 避免在同一个节点上运行多个NVIDIA设备插件实例
   • 特别注意CUDA基础镜像默认设置了NVIDIA_VISIBLE_DEVICES=all的特性

3. 监控方案：

   • 在API正式发布前，可以使用带CAP_SYS_ADMIN的DCGM作为临时监控方案
   • 考虑结合节点级监控作为补充

总结

Bottlerocket OS对GPU访问的安全限制是出于良好的安全设计考虑，虽然暂时影响了DCGM等工具的使用，但技术团队已经提出了明确的解决方案路线图。用户可以根据自身安全需求选择临时解决方案或等待即将发布的API功能。这一案例也提醒我们在容器化环境中平衡功能需求与安全边界的重要性。