前阵子帮一个团队把训练任务迁到 K8s 集群上第一反应是按 CPU 任务那套思路走不就行了requests、limits 写满剩下的交给调度器。结果 Pod 跑起来才发现GPU 这件事根本没那么简单——调度器明明告诉你显卡已经分配出去了容器里就是起不来或者更离谱一堆 Pod 挤在同一张卡上谁也不让谁显存爆了都不吭一声。这篇我把自己从零开始把 GPU 接入 K8s 的完整过程梳理一遍从底层机制讲到生产实操再把我踩过的坑挨个说清楚最后聊聊 NPU、FPGA 这类异构设备怎么复用同一套体系。不管你是刚开始接触 GPU 调度还是已经被设备插件折腾到头大这篇都值得收藏。1. GPU 的特殊性和 K8s 资源模型之间的适配层1.1 K8s 原生的资源计量方式对 GPU 并不适用K8s 的调度器在设计上有一个基本假设资源可以被数值化、被共享、被隔离。CPU 按核和毫核计内存按字节计容器没跑满内核就闲在那可以分给别的 Pod 用。Cgroup 负责做限额调度器负责做分配这一整套在 CPU/内存上运行得非常好。但 GPU 完全不同。一张显卡是一个插在 PCIe 槽上的物理设备它同时包含了两类不可分割的属性一个是显存一个是计算单元SM / CUDA Core。你没法用毫卡这样的单位去描述它也没法像内存一样把一个设备切给多个进程任意使用。更关键的是GPU 驱动是装在宿主机上的内核模块容器镜像里装的那套 CUDA 工具包只是用户态库没有宿主机的驱动配合容器里根本调不起来。所以如果你只是简单声明一个resources.limits[example.com/gpu] 1K8s 会直接拒绝调度因为它压根不认识这个资源。这就引出了第一个核心概念扩展资源Extended Resource。K8s 允许自定义资源名格式是厂商域名加资源名比如nvidia.com/gpu。但扩展资源有一个很讨厌的限制——在 1.20 之前你只能设置它的 requests不能设置 limits。也就是说调度器按你请求的数量把显卡分出去了但 Pod 对这张卡到底能用到什么程度的资源系统完全不管。1.20 之后才允许为扩展资源设置 limits但即便设置了也只是在调度阶段起作用运行时的隔离仍然要靠驱动和容器运行时去完成。1.2 Device Plugin 承担了发现设备和注入设备两件事既然 K8s 不认识 GPU那就需要有人把 GPU 包装成它认识的样子。这个中间层就是 Device Plugin。它的工作听起来很简单实际上分成了两条完全不同的链路。第一条链路是资源上报。Device Plugin 以 DaemonSet 形式跑在每个 GPU 节点上启动时向 kubelet 注册一个 Unix socket通常在/var/lib/kubelet/device-plugins/下面然后通过 ListAndWatch 接口把当前节点上可用的设备列表告诉 kubelet。kubelet 拿到这个列表后会把它转成扩展资源上报到 Node 对象的 Capacity 和 Allocatable 字段里。你执行kubectl describe node看到nvidia.com/gpu: 8就是这一步的产物。第二条链路是设备分配。当调度器决定把一个请求了nvidia.com/gpu: 1的 Pod 调度到某个节点上时kubelet 会去调用对应 Device Plugin 的 Allocate 方法。这个方法的职责是在容器真正启动之前告诉容器运行时这个容器要用哪个物理设备、要注入哪些环境变量、要把宿主机的哪些目录挂载进容器。典型场景下Allocate 会返回/dev/nvidia0这样的设备节点、NVIDIA_VISIBLE_DEVICES0这样的环境变量以及/usr/local/nvidia这样的驱动目录挂载。一句话总结调度器只负责看数字kubelet 负责把数字翻译成真实设备。设计这个插件的初衷也在这里——各家芯片厂商的设备差异太大与其在 K8s 内核里硬写死所有硬件细节不如把这层做成插件化的接口谁家的设备谁自己写驱动对接。1.3 为什么容器里已经装了 CUDA还是跑不起来这是很多新手问得最多的问题。镜像里nvcc --version能正常输出程序一跑就报找不到 CUDA driver甚至nvidia-smi直接提示无法与驱动通信。原因在于 CUDA 栈分成两层内核态的驱动NVIDIA kernel module和用户态的运行时库。容器镜像里装的 CUDA Toolkit 只是用户态那部分它需要和宿主机上匹配的内核驱动协作。容器运行时Docker 或 containerd在创建容器时需要把宿主机驱动相关的目录、设备节点、以及libcuda.so等动态库注入到容器内部这一步通常由 nvidia-container-toolkit 完成。如果少了这个环节容器内部能看到的只有自己镜像里的库文件没有和内核驱动对接的通道自然跑不起来。所以完整接入 GPU 的链路是宿主机装好 NVIDIA 驱动再装 nvidia-container-toolkit让容器运行时具备注入 GPU 设备的能力最后在 K8s 里部署 NVIDIA Device Plugin把 GPU 变成可调度的资源。这三层缺一不可而且每一层的配置都藏了不少坑。2. 把一套可用的 GPU 调度环境完整跑起来2.1 节点侧准备驱动、运行时、容器工具链先说明一下我这里假设你已经有一台装好 NVIDIA 显卡的 Linux 服务器操作系统是 Ubuntu 20.04 或 22.04容器运行时是 containerd。如果你的环境不同思路是一样的不过路径和包管理器要自己替换。宿主机先确认驱动是否正常nvidia-smi如果能看到类似下面的输出说明驱动层面没问题--------------------------------------------------------------------------------------- | NVIDIA-SMI 545.23.08 Driver Version: 545.23.08 CUDA Version: 12.3 | ---------------------------------------------------------------------------------------接下来安装 nvidia-container-toolkit。它是让容器能够访问 GPU 的关键工具。官方仓库里有安装脚本我这里习惯手动操作distribution$(. /etc/os-release;echo $ID$VERSION_ID) curl -s -L https://nvidia.github.io/nvidia-container-runtime/gpgkey | sudo apt-key add - curl -s -L https://nvidia.github.io/nvidia-container-runtime/$distribution/nvidia-container-runtime.list | sudo tee /etc/apt/sources.list.d/nvidia-container-runtime.list sudo apt-get update sudo apt-get install -y nvidia-container-toolkit装完之后需要让 containerd 认识 nvidia runtimesudo nvidia-ctk runtime configure --runtimecontainerd sudo systemctl restart containerd这一步会自动修改/etc/containerd/config.toml把 nvidia 运行时注册进去。改完之后你可以打开这个文件看一眼确认里面出现了 runtime 名为nvidia的配置。如果不做这一步后面 Pod 申请 GPU 时会报 Unknown runtime specified nvidia这个错误我后面排查章节会展开讲。2.2 部署 NVIDIA Device Plugin节点准备好之后就可以在集群里部署 Device Plugin 了。NVIDIA 官方提供了一个默认的 DaemonSet manifest直接用即可kubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.14.1/nvidia-device-plugin.yml但直接这样用有一个问题默认配置里没有设置容忍Toleration也不会自动选择 GPU 节点。如果你的 GPU 节点上有特殊污点或者你希望只在大显存机器上启用这个 DaemonSet需要自己改一版。我一般会写成下面这样apiVersion: apps/v1 kind: DaemonSet metadata: name: nvidia-device-plugin-daemonset namespace: kube-system spec: selector: matchLabels: name: nvidia-device-plugin-ds updateStrategy: type: RollingUpdate template: metadata: labels: name: nvidia-device-plugin-ds spec: tolerations: - operator: Exists containers: - image: nvcr.io/nvidia/k8s-device-plugin:v0.14.1 name: nvidia-device-plugin-ctr securityContext: privileged: true volumeMounts: - name: device-plugin mountPath: /var/lib/kubelet/device-plugins - name: driver mountPath: /usr/local/nvidia volumes: - name: device-plugin hostPath: path: /var/lib/kubelet/device-plugins - name: driver hostPath: path: /usr/local/nvidia这里有个地方值得注意driver 卷的挂载路径/usr/local/nvidia在某些操作系统或驱动安装方式下可能不存在。比如你用的是 runfile 方式安装的驱动目录结构可能不一样。稳妥起见部署之前先在节点上确认一下这个目录是否存在不存在就改成实际路径或者把挂载去掉。Device Plugin 默认配置下是不需要这个挂载的但一些特殊参数会用到宁可按官方默认来。部署完成后等 DaemonSet 的 Pod 都处于 Running 状态执行kubectl describe node gpu-node如果一切正常输出里应该能看到Capacity: nvidia.com/gpu: 8 cpu: 16 memory: 64367416Ki Allocatable: nvidia.com/gpu: 8 cpu: 16 memory: 62578904Ki看到这个说明 Device Plugin 已经成功把 GPU 资源上报给 kubelet 了。2.3 验证 GPU Pod 是否真正拿到了显卡资源上报成功不代表调度和注入一定没问题。跑一个最基础的单卡 Pod 验证一下apiVersion: v1 kind: Pod metadata: name: gpu-test spec: restartPolicy: OnFailure containers: - name: cuda-test image: nvidia/cuda:12.2.0-base-ubuntu22.04 command: [nvidia-smi] resources: limits: nvidia.com/gpu: 1创建后看日志kubectl logs gpu-test能输出完整的 nvidia-smi 信息就说明这条链路已经通了。输出信息中会看到你自己那张卡的型号、显存、驱动版本。每次看到这一步成功我都会安心很多——因为后面所有复杂的调度、共享、限流操作都是在这条链路之上做的。2.4 资源声明里的几个关键参数nvidia.com/gpu这个资源名在 YAML 里怎么用有几种写法值得明确一下。写法含义建议limits.nvidia.com/gpu: 1只写 limitsrequests 会自动等于 limits最常用简单清晰requests.nvidia.com/gpu: 1 不写 limits在 1.20 之前唯一合法的写法但调度后无运行时限流老集群兼容时才会用limits.nvidia.com/gpu: 2申请两张卡同一 Pod 的两张卡可能来自同一节点多卡训练时使用我个人习惯在声明 GPU 时只写 limits 不写 requests因为对于扩展资源而言二者通常应当一致分开写反而可能出现调度器按 requests 分配、运行时却不知道要不要注入设备的问题。另外如果你需要申请 2 张卡调度器会尝试在同一个节点上找到 2 块空闲的 GPU找不到就 Pod 一直 Pending这个行为是调度器保证的你不用担心它会把两张卡拆到两个节点上。3. 单卡独占太浪费MIG、时间切片与显存共享的取舍3.1 MIG把一张大卡从硬件层面切成几段当我们讨论 GPU 利用率的时候首先要面对的问题是K8s 默认把一张卡当作一个不可分割的整体。哪怕你只是跑一个显存占用 2GB 的推理服务只要它申请了nvidia.com/gpu: 1调度器就会把整张卡从资源池里划走。在 8 卡机器上跑 8 个这种服务没问题但如果你有 40GB 显存的卡只跑几个小服务浪费就非常明显。MIGMulti-Instance GPU是 NVIDIA 从 A100 开始提供的硬件级切分能力。它可以把一张物理 GPU 划分成多个独立的 GPU 实例每个实例拥有独立的显存、独立的计算单元和独立的高速缓冲。你可以把一张 A100 40GB 切成 7 个 1g.5gb 实例每个实例约 5GB 显存相互之间在硬件层面隔离互不干扰。启用 MIG 之后Device Plugin 默认并不直接感知这些实例。你需要先在节点上用nvidia-smi mig -cgi配置好 MIG 模式然后通过 NVIDIA 官方的 mig-parted 工具或修改 Device Plugin 配置把 MIG 实例暴露为nvidia.com/mig-1g.5gb这样的资源。调度器看到的就是更细粒度的资源池Pod 可以按需指定要 1g.5gb 还是 2g.20gb。这个能力对大卡场景意义非常大我接触过的几个做推理服务的团队靠 MIG 把卡利用率从不到 20% 拉到了 60% 以上。3.2 时间切片让多个 Pod 轮流用同一张卡MIG 要求显卡硬件支持而且固定的切分方式不一定适合所有业务。如果你的显卡不支持 MIG或者你想让多个业务共享一整张卡的算力那可以考虑时间切片Time Slicing。时间切片的原理很简单GPU 的算力本质是靠硬件调度器把任务分发给计算核心执行的多个进程可以同时提交任务GPU 硬件本身就支持多上下文并发。默认情况下 Device Plugin 把一张卡只报告为一个资源所以多个 Pod 没法同时调度到它上面。时间切片配置可以让同一个物理设备上报为多个副本这样调度器就会认为这张卡上有多块虚拟 GPU可以把多个 Pod 安排上来。配置方式是在 Device Plugin 启动时挂载一个配置文件例如version: v1 sharing: timeSlicing: resources: - name: nvidia.com/gpu replicas: 4保存成 config.yaml 后在 DaemonSet 里加一个 volume 挂载到/etc/nvidia/下面再用--config-file/etc/nvidia/config.yaml启动即可。生效之后节点上报的nvidia.com/gpu可用数量会从 8 变成 32假设 8 张卡每张复制 4 份。但这只是调度层面的数量变化底层算力仍然是轮转共享的。这里必须说清楚一个容易误解的点时间切片不隔离显存。多个 Pod 共享同一张卡时如果其中一个 Pod 把显存吃满其他 Pod 会直接申请不到显存甚至 OOM。算力方面同样存在干扰某个 Pod 跑满计算单元时邻居 Pod 的延迟会明显上升。所以时间切片适合容忍延迟波动、负载不密集的场景比如开发调试环境不太适合对延迟和显存都有严格要求的线上推理服务。3.3 厂商 vGPU 方案和自研共享方案除了 MIG 和时间切片一些厂商还提供 vGPU 方案。这类方案通过修改驱动和容器运行时在软件层面把一张物理卡虚拟化成多张看起来独立的逻辑卡每张卡有独立的显存配额和算力限额。相比时间切片这类方案通常能提供更好的显存隔离和算力限制能力。不过部署复杂度更高需要特定版本的驱动和运行时支持部分方案还涉及商业化授权。如果你所在的团队已经有某云厂商的整套 GPU 解决方案直接用它们提供的调度插件往往比自己从头搭省很多事但如果你想完全掌控底层行为做更精细的调优我自己会倾向于 MIG 加时间切片的组合。方案显存隔离算力隔离支持硬件适合场景单卡独占完全隔离完全隔离所有 NVIDIA 卡训练任务、性能敏感服务MIG硬件级隔离硬件级隔离A100/H100 等推理服务、多租户隔离时间切片无隔离无隔离所有 NVIDIA 卡开发调试、低负载轻服务vGPU 方案软件级隔离软件级限额取决于实现多租户共享、资源超卖选型的核心逻辑其实只有一条看你的业务对性能干扰的容忍度。如果你要给多个客户提供推理能力MIG 这种硬件隔离最稳妥如果只是内部开发环境时间切片提高利用率已经足够了。4. 排查 GPU 调度问题的完整链路4.1 节点就绪但 GPU 资源数为 0 的排查顺序这是我见过的最高频问题。节点状态是 Ready但kubectl describe node里完全没有nvidia.com/gpu这个资源。遇到这种情况我一般按下面的顺序逐步排查第一步确认节点上是否真的能看到显卡nvidia-smi如果这里就报错说明驱动层面已经出了问题后面什么都别看了。如果正常进入第二步。第二步看 Device Plugin Pod 的日志kubectl logs -n kube-system nvidia-device-plugin-pod重点看有没有出现类似 Failed to connect to kubelet 或 Failed to register with device plugin 的信息。如果日志显示注册成功但节点上还是没有资源那问题可能出在 kubelet 侧。第三步检查 kubelet 的 device-plugins 目录。正常情况下应该有如下两个文件存在ls /var/lib/kubelet/device-plugins/如果你看到了kubelet.sock和device-plugin.sock说明 kubelet 和 Device Plugin 之间的通信链路至少是通的。如果只有一个kubelet.sock说明 Device Plugin 压根没完成注册。第四步检查 containerd 的 runtime 配置。我遇到过一次很隐蔽的问题节点上 device-plugin Pod 状态正常但注册时上报的设备数始终是 0。后来排查发现nvidia-ctk runtime configure虽然改了配置文件但 containerd 没有完全重启成功导致实际运行时用的还是旧配置。执行systemctl restart containerd后问题立刻解决。这个排查链路里最核心的心得是先看硬件再看插件最后看运行时。不要一上来就怀疑 K8s 调度器因为调度器只是读取节点上报的数据数据源本身就有问题的话调度层面再查也查不出结果。4.2 容器启动报错从驱动版本不匹配到 NVML 初始化失败驱动和 CUDA 版本相关的报错是另一个高频踩坑点。最常见的场景是某天有人升级了宿主机驱动之后所有 GPU Pod 都起不来日志里全是Failed to initialize NVML: Driver/library version mismatch这个错误的本质是内核里加载的驱动模块nvidia.ko和用户态的 NVIDIA 库文件libnvidia-ml.so等版本不一致。升级驱动时内核模块可能在重启后才会加载新版本但用户态库已经被替换成了新版于是两边对不上。这种时候不要急着改 Device Plugin 配置先恢复到能用的驱动版本或者重启节点让内核模块重新加载。我踩过一次之后养成了一个习惯任何驱动升级都会先确认节点上的 nvidia-smi 输出恢复正常并跑一个简单的 GPU Pod 验证完才把它放回生产调度池。另一个常见报错是这样的could not select device driver with capabilities: [[gpu]]这个通常意味着容器运行时没有正确配置 nvidia runtime。你可以在节点上手动执行ctr run --rm --runtime nvidia --gpus 1 image name nvidia-smi如果这里就报错那就是 containerd 配置问题和 K8s 无关继续回到nvidia-ctk runtime configure那一步。4.3 显存超限的假性成功有一类问题最迷惑人因为它表面上调度成功了Pod 也在运行但实际行为是错的。时间切片场景下多个 Pod 共享一张物理卡但 Device Plugin 报给调度器的每个副本都不带显存配额信息。如果某个 Pod 里的程序把显存吃满同卡的其他 Pod 申请显存时会直接失败。我遇到过的情况是两个推理服务同时被调度到一张卡上一个服务在高峰时把显存吃到 100%另一个服务的请求开始大量报错。但从 K8s 层面看两个 Pod 都是 Running 状态资源也满足请求。因为共享模式下nvidia.com/gpu的计数已经被超卖了。这类问题靠 K8s 的资源监控很难发现最好在业务侧给 GPU 进程设置显存上限或者使用支持显存配额限制的实际方案避免把问题留到运行时。4.4 多卡 Pod 的拓扑问题申请多张卡做训练时你可能还会遇到一个比较底层的性能问题Pod 分配到了两张卡但这两张卡之间没有 NVLink 直连而是走 PCIe 通信。NVLink 带宽远高于 PCIe数据交换效率差别很大。K8s 默认调度器不感知 GPU 之间的物理拓扑所以两张卡很容易被分配到不理想的组合上。对于这个问题如果想优化有两条路可选。一是给节点打 label将拓扑结构在 K8s 层面建模然后通过自定义调度器或调度插件约束 Pod 的分配。二是使用 NVIDIA 提供的 topology-aware device plugin 或专门的调度扩展比如某些集群方案里会用 label 标记 GPU 编号和 NVLink 域。实践上我通常先跑nvidia-smi topo -m看节点上的拓扑再结合业务对通信带宽的要求决定值不值得上调度扩展。对于仅做小规模推理服务的团队这个优化点可以先放一放优先级远低于前面几个问题。5. 异构设备管理从 GPU 到 NPU、FPGA 的同一套思路5.1 不只是 GPU其他加速卡也走 Device Plugin 这条路标题里那个等字其实才是很多平台团队真正头疼的地方。现在做 AI 基础设施面对的加速设备远不止 NVIDIA GPU有各种 AI 芯片常说的 NPU、AI 加速卡、FPGA 板卡、RDMA 网卡甚至视频编解码卡。如果每种设备都要在 K8s 里另起炉灶那整个平台会变得非常碎片化。好在 Device Plugin 这套机制是通用的。任何能让宿主操作系统识别、并且能通过某种方式注入到容器里的设备理论上都可以实现自己的 Device Plugin。你只需要实现几个接口注册、上报设备列表、处理分配请求。很多国内芯片厂商都提供了自家设备的 K8s Device Plugin调度模型和 GPU 完全一致只是资源名变成了vendor.com/xxx之类的形式。这意味着你在学 GPU 管理时积累的所有经验——扩展资源怎么声明、DaemonSet 怎么部署、节点 label 怎么规划——可以原封不动地迁移到其他异构设备上。我自己在帮助团队设计异构资源池时习惯把调度层和业务层做清晰的边界。调度层只关心节点的资源上报和 Pod 的分配需求业务层则按资源名请求设备。这样后续接入新加速卡时只要新增一个 device plugin 和几条节点 label业务代码几乎不需要改动。5.2 K8s 未来的方向Dynamic Resource Allocation如果你有精力紧跟社区动态会发现 K8s 正在酝酿一个更大的变化Dynamic Resource AllocationDRA。传统的扩展资源模型只能表达我要 1 块 GPU这种整数数量的诉求没法表达我要一块显存不低于 8GB 的卡这类更细的需求。DRA 引入了 ResourceClaim 资源对象把资源请求和具体设备参数分离由各个厂商的 ResourceDriver 负责决定如何满足这个请求。DRA 在 1.26 版本以 alpha 引入之后一直在快速迭代中。它的意义在于把之前散落在各个 Device Plugin 里的分配逻辑进一步标准化和参数化未来不同类型的硬件设备可能真的可以用一套统一的方式管理起来。不过它的成熟度和生态完善还需要时间现阶段我的建议是先把传统的 Device Plugin 机制吃透因为绝大多数生产集群仍在此基础上运行而 DRA 的设计理念也会持续借鉴这些实践经验。写到这里把 GPU 接入 K8s 这条路线大概理清了。最后分享一点个人习惯我在生产环境搭 GPU 资源池时一定会先做好两件事一是把 GPU 监控指标显存使用率、算力利用率、温度接入现有监控体系二是把节点上的 GPU 数量和型号通过 label 标注清楚。前者让共享方案出了问题能及时发现后者是后续做拓扑调度、异构管理的基础也是排查问题时最快的入口。GPU 管理这件事没有一步到位的方案从单卡独占到细粒度共享每前进一步都要对业务有足够了解先把基础链路做稳再考虑怎么把利用率压上去。