Kubernetes GPU 集群十大坑：调度、网络和存储篇
基础设施不需要漂亮话。
GPU 集群和普通 CPU 雨群的区别，不只是贵了十倍，而是运维难度也贵了十倍。我们团队管理一个 40 节点的 GPU 集群半年，踩了十个坑，每一个都花了至少一天排查。这篇文章把调度、网络和存储三个维度的坑全部列出来，附带解决方案。
一、背景：GPU 集群为什么比 CPU 集群难管
GPU 资源有三个特点：昂贵、稀缺、不可细粒度共享。CPU 可以按核心分配，一台 64 核的机器可以跑几十个服务。GPU 不行，一个推理服务往往独占整张卡，8 卡节点上最多跑 8 个服务。
这三个维度的问题互相关联：调度失败了可能是因为存储没准备好，网络问题可能表现为 NCCL 初始化超时，存储瓶颈可能被误判为调度问题。
二、调度篇四大坑
坑 1：GPU 资源碎片化——8 卡节点只剩 1 卡可用
场景：一个 8 卡 A100 节点上，7 张卡被不同服务占用，剩 1 张空闲。新来了一个需要 2 卡的训练任务，调度器找不到合适的节点，任务一直 Pending。
更糟糕的情况：集群总共有 80 张 GPU，但碎片化后，任何需要 4 卡以上的任务都无法调度。GPU 利用率 87%，但有效利用率可能只有 30%。
解法：
- 使用 GPU 共享插件（如 NVIDIA GPU Operator 的时间片模式）让小推理任务填碎片。
- 训练任务使用 Gang Scheduling，要么全部 GPU 一起调度，要么不调度。
- 定期用 Descheduler 重平衡，把碎片化节点上的 Pod 搬到更紧凑的位置。
坑 2：Pod 调度失败但不告诉你原因
GPU Pod 一直 Pending，kubectl describe pod 只显示 "0/40 nodes are available"。不告诉你是因为 GPU 数量不够、节点有污点、还是亲和性规则冲突。
排查 GPU 调度失败的流程比 CPU Pod 复杂 5 倍，因为 GPU 资源不在标准 Node 的 allocatable 字段里，需要看 nvidia.com/gpu 这个扩展资源。
解法：
- 写一个调度诊断脚本，自动检查每个节点的 GPU 可用量、污点、亲和性。
- 用 kubectl get nodes -o custom-columns=NAME:.metadata.name,GPU:.status.allocatable.nvidia\\\\.com/gpu 快速查看 GPU 分配。
- 给关键训练任务加 schedulerName 使用自定义调度器，记录详细的调度决策日志。
坑 3：扩容震荡——Cluster Autoscaler 刚扩完就缩
GPU 节点从云厂商按需购买，一台 A100 节点每小时 30-50 元。Autoscaler 在高峰期扩了 5 个节点，高峰过后 10 分钟内就把这 5 个节点缩掉了。但下一个高峰 30 分钟后就来，又扩 5 个节点。一天扩缩 8 次，每次扩容要等 3-5 分钟节点初始化。
结果：业务方在每次扩容窗口期间请求全部排队，而云厂商按整小时计费，缩了又扩等于白花钱。
解法：
- 设置 scale-down-delay-after-add 至少 30 分钟，扩容后不急着缩。
- GPU 节点组单独配置，和 CPU 节点组的扩缩策略分开。
- 使用预留实例（Reserved Instance）覆盖基线负载，按需实例只做弹性补充。
坑 4：优先级抢占导致训练中断
在线推理服务设了高优先级，训练任务设了低优先级。高峰期推理服务扩容，抢占训练任务的 GPU。训练任务被驱逐，已经跑了 12 小时的训练从头再来。
解法：
- 训练任务使用 PodDisruptionBudget，最少保留一定数量的 Pod 不被驱逐。
- 推理和训练分不同节点池，物理隔离优先级抢占。
- 训练任务实现 checkpoint 定期保存，被驱逐后可以从最近的 checkpoint 恢复，不用从头开始。
三、网络篇三大坑
坑 5：多卡推理的 NCCL 通信卡死
多卡分布式推理依赖 NCCL 进行 GPU 间通信。NCCL 初始化时要发现所有参与 GPU 的拓扑关系，然后建立通信通道。如果网络配置不对，NCCL 初始化可能卡 10 分钟然后超时退出。
常见原因：CNI 插件没有正确配置 GPU 节点间的路由，或者 firewall 规则阻断了 NCCL 使用的端口范围（通常是 50000-60000）。
解法：
- GPU 节点间使用 RDMA 网络（RoCE 或 InfiniBand），NCCL 优先用 RDMA 绕过 CPU。
- 确认 CNI 配置允许 GPU Pod 间的直连通信，不要走 NAT。
- 在 NCCL 环境变量中设置 NCCL_DEBUG=INFO，初始化失败时能看到详细的拓扑发现日志。
- 给多卡 Pod 设置 hostNetwork: true，减少一层网络封装开销。
坑 6：GPU Pod 间直连通信被 Service 阻断
Kubernetes Service 默认用 iptables 或 IPVS 做负载均衡，会把流量分散到不同 Pod。但多卡推理需要指定 GPU 之间的通信对，不能被负载均衡打散。
解法：
- 多卡推理 Pod 使用 StatefulSet，每个 Pod 有稳定的网络标识。
- GPU 间通信使用 Pod IP 直连，不走 Service。
- 如果必须走 Service，用 Headless Service 返回所有 Pod IP，客户端自己选择目标。
坑 7：大规模 Pod 的 DNS 解析变慢
一个 GPU 集群上跑 200+ 推理服务 Pod，每个 Pod 启动时要做 DNS 解析发现其他服务。CoreDNS 单副本扛不住这个解析压力，Pod 启动时间从 5 秒变成 30 秒，其中 25 秒在等 DNS。
解法：
- CoreDNS 部署多个副本，用 HPA 根据 QPS 自动扩缩。
- 调整 NodeLocal DNSCache，在每个节点上缓存 DNS 结果，减少对 CoreDNS 的直接查询。
- Pod 的 /etc/resolv.conf 设置 ndots:2，减少不必要的搜索域查询。
四、存储篇三大坑
坑 8：模型权重 PVC 挂载失败
模型权重文件 10-50GB，存储在 NFS 或 Ceph 上。Pod 启动时挂载 PVC，如果存储后端响应慢，挂载可能要 60 秒以上。Kubernetes 默认的 Pod 启动超时可能比这个时间短，导致 Pod 被杀掉重启。
更常见的问题：多个 Pod 同时挂载同一个 PVC（只读模式），存储后端扛不住并发读，第一个 Pod 挂载成功，后面的 Pod 挂载超时。
解法：
- 模型权重用 Local PV + 节点预分发。每个 GPU 节点本地有一份模型文件，Pod 启动直接从本地磁盘加载。
- 对于必须用分布式存储的场景，用 CSI 驱动的 mountOptions 设置更长的超时时间。
- PVC 挂载完成后再触发模型加载，不要在容器启动脚本里假设挂载已经完成。
坑 9：本地缓存和分布式存储的取舍
推理服务加载模型后会在内存中缓存。但模型更新时，怎么保证所有副本同时更新？
- 分布式存储方案：所有 Pod 从同一个 PVC 读，更新一次所有 Pod 都能看到。但读取速度慢。
- 本地缓存方案：每个节点本地存一份，读取快但更新要逐节点同步，可能出现短暂版本不一致。
解法：混合策略。模型权重文件预分发到每个节点的本地 NVMe 盘上，通过 ConfigMap 或 CRD 管理当前版本。更新时发一个通知，所有节点异步拉取新版本到本地，拉取完成后再触发滚动更新。
坑 10：GPU 节点存储 IO 瓶颈
GPU 推理的瓶颈不在计算，而在数据喂给 GPU 的速度。如果存储 IO 慢，GPU 就在等数据，利用率显示 30% 但并不是因为模型小，而是因为数据通道慢。
实测数据：NFS 挂载的读取速度约 200MB/s，本地 NVMe 的读取速度约 3GB/s。7B 模型权重 14GB，NFS 加载需要 70 秒，本地 NVMe 只需要 5 秒。
解法：
- GPU 节点配备本地 NVMe 盘，用于模型权重和推理数据的缓存。
- CSI 驱动选择支持拓扑感知的方案，确保 PVC 在正确的节点上创建。
- 监控存储 IO 延迟，当 iowait 超过 10% 时触发告警。
五、避坑全景图
六、总结
GPU 集群的运维本质上是资源管理问题。十个坑的共性规律：
基础设施不需要漂亮话，管好 GPU 集群就是管好公司的钱。
