做算力调度平台环境准备是最容易糊弄、也最容易翻车的一步。我见过太多人把精力花在调度算法和平台架构上结果节点起来之后GPU容器跑不起来或者Docker一重启网络全乱。这个系列讲算力调度平台第二篇就先把环境准备这件事彻底捋清楚重点围绕Docker和GPU两条主线。这里适合两类人一是准备自建算力调度平台的运维或研发二是只想在本地把GPU容器环境跑通、方便复现深度学习任务的开发者。把这篇文章看完你会明白调度平台为什么依赖Docker做封装GPU直通到底卡在哪几个环节以及环境准备阶段哪些坑必须避开。我这里说的环境准备不是简单执行几条安装命令而是要把“宿主机驱动、容器运行时、调度资源模型”这三层关系理清否则后面平台跑起来排错成本会成倍增加。下面我先从为什么需要这套环境讲起再按实际部署顺序一步一步展开。1. 为什么算力调度平台绕不开Docker和GPU1.1 环境隔离与调度解耦算力调度平台要做的事情本质上就是把物理GPU切分成逻辑资源分给不同任务。如果没有容器化单纯靠进程隔离任务之间的Python版本、CUDA版本、系统依赖会互相打架。Docker在这里的价值是“能用”而是把环境做成不可变镜像调度器分发的是镜像节点只需要保证容器运行时和GPU驱动正常剩下的依赖全部固化在镜像里。这样上层调度逻辑与底层环境解耦节点故障恢复也快换一台节点拉镜像就能跑。我最早尝试过裸机方式管理环境每个节点用Anaconda装环境再用systemd管理进程。结果模型微调到一半某个依赖升级影响了另一组任务排查半天是动态库冲突。后来切到Docker类似问题基本绝迹。给调度平台做环境准备本质就是在给“可复现”打地基这一层不稳上层全是空中楼阁。1.2 GPU直通是算力调度的地基调度平台要调度GPU容器就必须能看到真实的GPU设备。这里有两个层面的支持驱动层和运行时层。驱动层由物理机上的NVIDIA驱动提供运行时层则需要把NVIDIA的库和工具挂进容器。两者缺一不可。只有驱动没有运行时容器里执行nvidia-smi大概率报错只有运行时没有驱动更是空谈。环境准备的重点就是让Docker在启动容器时能把宿主机的GPU设备及驱动库正确注入进去。这个过程并不神秘本质上就是给容器注入一组设备文件和动态库。但实际配置时很多人栽在版本匹配上。驱动版本、CUDA版本、NVIDIA容器工具包版本、镜像内CUDA版本任何一个错位都可能导致容器内识别不到GPU或者应用启动时直接报CUDA初始化失败。1.3 准备环境前必须先搞清楚的三件事动手之前先回答三个问题操作系统是什么、GPU型号是什么、调度平台打算跑在单机还是集群。操作系统决定安装方式GPU型号决定驱动版本单机还是集群决定你是只需Docker还是还要配Kubernetes的GPU插件。这三件事没想清楚后面很容易反复返工。以我自己的环境为例一台双路服务器4张NVIDIA显卡系统是Ubuntu 22.04调度平台先跑在单机Docker上后续要扩展到K8s。因此环境准备分两条线先把Docker和GPU容器运行时跑通再预留K8s的device plugin入口。下面每一步都是基于这个目标来的你的目标如果不同对应步骤可以裁剪。2. 环境检查动手装Docker之前先做这几步2.1 操作系统与内核版本核查Docker对内核版本有底线要求尤其是老系统。建议至少Linux Kernel 3.10以上长期运维的节点建议4.18以上Ubuntu 20.04和22.04默认内核都满足。检查命令很简单uname -a cat /etc/os-release如果发行版太老比如CentOS 6新版Docker已经不支持别想着硬装会浪费大量时间。我见过有人在老内核上装新版Docker启动时直接报unsupported kernel最后只能换系统。对于调度平台这种长期运行的底座不值得为了迁就旧系统降低Docker版本否则后续镜像兼容性会很难受。2.2 虚拟化与容器运行时的检查Windows端常见的问题是Docker Desktop提示virtualization support没开启需要在BIOS里打开VT-x或AMD-V并确认Windows功能里的“虚拟机平台”和“WSL2”两项已启用。Linux端则要检查是否已经装了其他容器运行时比如containerd或podman避免端口和socket冲突。检查当前Docker状态可以用systemctl status docker 2/dev/null || echo docker not installed ls /var/run/docker.sock 2/dev/null || echo no docker socket如果发现系统之前装过旧版Docker建议先清理不要覆盖安装。覆盖安装最典型的坑是新二进制覆盖了但旧配置还留在/etc/docker/daemon.json里导致镜像源或存储驱动不符合预期。我踩过一次明明改了daemon.jsonDocker就是不生效最后发现是旧进程没完全停干净。2.3 GPU设备与驱动识别检查NVIDIA驱动是否安装、能否看到GPU命令是nvidia-smi如果命令不存在先装驱动。如果命令存在但报错比如GPU is lost或者设备管理器错误代码43先别急着装Docker先把驱动问题解决。驱动装好后记录下驱动版本和CUDA版本例如Driver 535.154.05CUDA 12.2。这个信息在后面配置容器工具包和挑选镜像时非常关键。注意nvidia-smi显示的CUDA版本是驱动所支持的最高版本并不代表容器内必须用这个版本来跑程序。容器里可以向下兼容使用更低版本的CUDA镜像比如驱动支持12.2容器里跑CUDA 11.8的应用也没问题。但如果镜像的CUDA版本高于驱动支持版本就会在初始化CUDA上下文时报错。检查项命令或方法期望结果操作系统cat /etc/os-release记录版本号内核版本uname -r建议4.18以上GPU驱动nvidia-smi正常输出GPU列表Docker状态docker version客户端和服务端都正常虚拟化lscpu或BIOSVT-x/AMD-V已开启3. Docker安装与镜像源配置实操向3.1 在Linux服务器上安装Docker Engine如果用官方源安装在Ubuntu上按顺序执行以下命令sudo apt-get update sudo apt-get install -y ca-certificates curl sudo install -m 0755 -d /etc/apt/keyrings sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc echo deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu $(. /etc/os-release echo $VERSION_CODENAME) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null sudo apt-get update sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin装完后启动并设置开机自启sudo systemctl enable --now docker sudo docker run hello-world这里提醒一句不要把docker-compose-plugin漏掉后续编排调度平台组件经常用到。如果你所在环境无法访问download.docker.com就换用发行版自带包源安装但版本可能偏老。我个人建议能装官方源就装官方源版本新修复也多。3.2 Windows环境用Docker Desktop还是Docker EngineWindows上最常见的方案是Docker Desktop它自带WSL2后端和GUI。但如果你要做的算力调度平台面向的是Linux服务器集群Windows本机更适合做开发测试不建议作为生产节点。Docker Desktop设置WSL2后GPU支持相对简单只要在WSL里安装对应版本的NVIDIA驱动Windows驱动可以直接透传给WSL2然后在Docker Desktop设置里勾选“Use the WSL 2 based engine”后期跑带GPU的容器基本能开箱即用。如果你更想在Windows上用纯Docker Engine方式可以选择在WSL2发行版里安装Docker Engine而不是用Docker Desktop。这样少了GUI但和Linux服务器行为一致排错时也更可控。我个人更推荐后者做调度平台的开发模拟因为我后面写脚本也好、验证调度逻辑也好都直接在WSL2的终端里操作跟生产环境对得上。3.3 镜像源与存储驱动配置Docker安装完成后至少要检查两个配置镜像源和存储驱动。配置文件在/etc/docker/daemon.json典型配置如下{ registry-mirrors: [https://docker.m.daocloud.io], data-root: /data/docker, exec-opts: [native.cgroupdriversystemd], storage-driver: overlay2 }每次修改daemon.json之后要执行systemctl daemon-reload systemctl restart docker。data-root建议放到独立数据盘避免系统盘被镜像撑满。调度平台一到高峰期镜像层缓存能占几十GB放系统盘很容易把根分区写满届时Docker会拒绝任何写操作平台任务全部卡住。cgroupdriversystemd这个配置尤其重要。如果未来要接Kuberneteskubelet默认用systemd作为cgroup驱动Docker这里不保持一致节点加入集群时会报驱动不一致错误。即使现在只跑单机Docker也建议把这个参数写上省得以后集群化改造时再动配置重启Docker。4. GPU容器运行时让容器能调用显卡4.1 NVIDIA Container Toolkit安装要让Docker调用GPU光有驱动还不够还需要NVIDIA Container Toolkit。官方名称是NVIDIA Container Toolkit旧称nvidia-docker2。安装方法在Ubuntu上大致如下curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | sed s#deb https://#deb [signed-by/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list sudo apt-get update sudo apt-get install -y nvidia-container-toolkit安装完成后需要让Docker的运行时识别到NVIDIAsudo nvidia-ctk runtime configure --runtimedocker sudo systemctl restart docker这条命令会自动修改/etc/docker/daemon.json加入nvidia运行时配置。装完之后马上跑docker info看输出里是否出现nvidia字样没有就说明配置没生效。Google搜到的很多老教程还是nvidia-docker2时代的方法新版本已经统一为nvidia-container-toolkit不要装错。4.2 Docker默认运行时切换与配置nvidia-ctk runtime configure命令除了帮你加nvidia运行时还支持把它设为默认运行时。配置文件里会出现类似这样的一段{ runtimes: { nvidia: { args: [], path: nvidia-container-runtime } } }如果没有设置default-runtime那么跑GPU容器时必须显式加--gpus all参数。如果设置了default-runtime为nvidia那么所有容器默认都能访问GPU但也意味着安全面扩大每个普通容器都看得到GPU设备。在算力调度平台上我建议不要全量默认而是让调度器在启动任务时按需指定--gpus这样隔离性更好也不会出现一个调试容器把GPU占用掉的情况。4.3 验证GPU容器是否生效装完之后跑一张测试镜像docker run --rm --gpus all nvidia/cuda:12.2.0-base-ubuntu22.04 nvidia-smi如果能正常输出GPU列表说明设备映射和库注入都成功。如果报错docker: Error response from daemon: could not select device driver with capabilities: [[gpu]]说明容器工具包没有正确配置大概率是没执行nvidia-ctk runtime configure或者执行完后没有重启Docker。另外要注意镜像TAG里的CUDA版本不一定非得和宿主机驱动版本一致但不要高于驱动支持的最高版本。这个放在实操环节尤其容易踩有人拉了一个CUDA 12.3的镜像结果宿主驱动只支持12.1应用启动后直接段错误或者CUDA error。选镜像之前先看一眼nvidia-smi再决定拉哪个TAG能省很多时间。5. 算力调度场景下的进阶配置5.1 nvidia-smi与CUDA版本匹配在调度平台上每个任务可能会用不同CUDA版本的镜像。宿主机驱动是全局的只需要大于等于任务的CUDA版本即可。一个实用建议宿主机驱动尽量更新这样既能兼容老CUDA镜像也能跑新CUDA镜像。驱动版本与CUDA版本对照关系可以参考NVIDIA官方文档安装驱动时别选latest随便装至少确认它支持你们业务里最常用的CUDA版本。另一个常被忽略的点nvidia-smi看到的GPU显存是物理显卡的总显存但容器默认不会限制显存一个任务可以直接耗尽整张卡显存。调度平台的设计上需要在框架层做显存配额Docker本身没有原生的显存限制除开较新的MIG硬件特性。所以环境准备阶段要提前确定到底打算用多少张卡、多少显存作为最小分配单元。这个决定会直接影响调度器的资源模型。5.2 为调度平台预留的资源上限Docker可以对CPU和内存做限制但对显存的控制比较有限。通常做法是平台管理组件单独放在非GPU节点或者使用非常小的GPU比例GPU节点专注于算力任务。同时建议在docker run时设置--cpus和--memory避免一个失控任务打爆宿主机。示例docker run -itd --name task-01 --gpus device0,1 --cpus16 --memory64g nvidia/cuda:12.2.0-base-ubuntu22.04 sleep infinity如果你的平台允许任务共享一张卡可以只指定device0再通过镜像内的训练框架限制显存占比。但要注意多个容器共享一张卡时显存分配完全看任务自身行为一旦有一个任务显存泄漏整张卡可能OOM进而影响其他任务。所以环境准备阶段就要把“单卡独占”还是“单卡共享”的策略定下来并在调度器里实现对应的分配逻辑。5.3 K8s环境里的GPU扩展点如果你的算力平台从单机Docker走向K8s一定要关注device plugin机制。NVIDIA官方提供了GPU device plugin作为DaemonSet部署到每个GPU节点这样K8s调度器才能感知GPU资源并做分配。同时需要为每个节点打标签比如nvidia.com/gpu.presenttrue并且通过Extended Resource方式暴露nvidia.com/gpu。这些字段在环境准备阶段就要想好因为节点是否安装了NVIDIA Container Toolkit决定device plugin能不能探测到GPU。如果你不是立刻上K8s至少保持daemon.json里的cgroupdriversystemd一致避免将来整改。真正的算力平台到了多节点以后一定离不开K8s的调度能力所以环境准备不是只给Docker用的而是给“容器加资源调度”设计好底子。现在多花十分钟把配置写对之后集群化会顺利很多。6. 常见问题与排查技巧实录6.1 Docker Desktop启动失败虚拟化未开启Windows端最常见的报错是Docker Desktop failed to start because virtualisation support isnt detected。处理分三步第一步BIOS里启用VT-x或AMD-V第二步Windows功能开启“虚拟机平台”和“适用于Linux的Windows子系统”第三步以管理员身份运行bcdedit /set hypervisorlaunchtype auto然后重启。多数情况下重启就能解决。如果还不行检查是否和其他虚拟机软件冲突比如老版本VirtualBox可能干扰Hyper-V。6.2 Linux容器里执行nvidia-smi提示not found原因通常是宿主机驱动正常但容器里缺少NVIDIA工具库。在正确配置NVIDIA Container Toolkit后运行时会把宿主机的库注入容器不应该出现not found。解决思路先跑官方镜像而不是自打包镜像排除镜像问题再检查daemon.json里runtimes配置最后手动执行nvidia-ctk runtime configure --runtimedocker并重启Docker。6.3 GPU错误代码43Windows上经常出现设备管理器里NVIDIA显卡错误代码43本质是驱动或硬件层面的问题不是Docker的锅。先用DDU卸载干净驱动再安装厂家认证版本如果使用WSL2确保Windows驱动版本支持WSL2。出现43代码时先修好宿主机GPU不要试图用容器绕过宿主机故障否则后面训练任务会莫名其妙失败。6.4 Docker拉取镜像慢或超时拉取镜像失败大多是网络问题。配置registry-mirrors后一般会改善但注意不是所有镜像源都稳定建议一个不够就配两三个。实际操作中我还遇到过镜像源配置了但docker pull默认还是走官方仓库排查后发现Docker服务没有加载新的daemon.json重启一次就好。镜像源要避免使用容易被干扰的服务尽量选择多个备用源。6.5 权限问题docker run需要sudo把当前用户加入docker组sudo usermod -aG docker $USER newgrp docker加入后重新登录一般就不用sudo了。不过要注意docker组等同于root权限不要随便把不信任的用户加进去。算力调度平台管理节点尤其要小心给一个普通开发开docker权限等于把主机的root权限也给他了。权限边界要在环境准备阶段就划清楚别等出了问题再补救。环境准备这件事看起来只是装个软件其实是在给整个调度系统划边界。我在实际部署中最大的体会是先把驱动版本、CUDA版本、容器运行时版本这三者的匹配关系画成一张表贴到机房的墙上每次出问题先看表能省下大半排查时间。另外所有配置改动前都先备份daemon.json别嫌麻烦。算力调度平台能不能稳定运行往往不是调度算法多高明而是环境底子有没有打扎实。