Volcano项目中的GPU资源重复分配问题分析与解决方案

问题背景

在Kubernetes集群中使用Volcano调度器管理GPU资源时，发现当多个Pod分批次请求同一节点上的GPU资源时，会出现GPU设备被重复分配的问题。具体表现为：不同Pod被分配了相同的GPU设备ID，这显然违背了GPU独占使用的原则，可能导致严重的计算错误和资源冲突。

问题现象

在实际测试场景中，我们观察到以下现象：

1. 在一个拥有8块GPU（ID为0-7）的节点上
2. 依次创建三个Pod，分别请求2、2和4块GPU
3. Pod不是同时创建，而是有间隔地分批创建
4. 结果发现GPU 1和2被同时分配给了Pod1和Pod3

通过kubectl检查Pod的annotation可以看到：

• Pod1被分配了GPU 1和2
• Pod2被分配了GPU 7和0
• Pod3被分配了GPU 0、1、2和3

这明显出现了GPU 1和2被重复分配的情况。

问题根因分析

经过深入分析Volcano调度器的源码，发现问题出在节点GPU资源管理机制上：

1. 资源记录不完整：调度器通过ssn.Node[nodename].GPUDevices[dev-id]结构记录GPU设备的使用情况，包括已被现有Pod占用的GPU和当前调度周期内分配的GPU。

2. GPU数量资源未正确记录：当前实现中，AddGPUResource函数只处理使用volcano.sh/gpu-memory资源的Pod，而忽略了使用volcano.sh/gpu-number资源的Pod。这导致使用GPU数量资源的Pod不会被记录到GPU设备占用信息中。

3. 调度决策错误：由于上述记录缺失，调度器在进行新Pod调度时，会错误地认为那些已被gpu-number类型Pod占用的GPU设备仍然可用，从而导致重复分配。

解决方案

针对这一问题，我们提出了以下修复方案：

修改AddGPUResource函数，使其同时考虑使用GPU内存资源和GPU数量资源的Pod。具体修改如下：

func (ni *NodeInfo) AddGPUResource(pod *v1.Pod) {
    gpuRes := GetGPUMemoryOfPod(pod)
    gpuNumRes := GetGPUNumberOfPod(pod)
    if gpuRes > 0 || gpuNumRes > 0 {
        ids := GetGPUIndex(pod)
        for _, id := range ids {
            if dev := ni.GPUDevices[id]; dev != nil {
                dev.PodMap[string(pod.UID)] = pod
            }
        }
    }
}

关键改进点：

1. 同时获取Pod的GPU内存需求和GPU数量需求
2. 只要任一需求大于0，就将Pod记录到对应GPU设备的占用信息中
3. 确保所有使用GPU资源的Pod都能正确反映在调度器的资源记录中

验证结果

修复后，我们重新进行了测试：

1. 创建4个Pod，每个请求1块GPU，间隔3秒创建
2. 确认每个Pod被分配了不同的GPU设备ID
3. 没有出现GPU设备重复分配的情况

测试结果符合预期，证明了修复方案的有效性。

技术启示

这个问题给我们带来以下技术启示：

1. 资源管理完整性：在实现资源调度器时，必须确保对所有资源类型的完整记录和管理，避免因资源类型不同而导致的管理缺陷。

2. 调度器状态一致性：调度器维护的资源状态必须与实际集群状态保持严格一致，任何不一致都可能导致严重的调度错误。

3. 测试覆盖全面性：需要设计覆盖各种资源请求类型的测试用例，包括不同资源类型、不同请求方式的组合场景。

4. 资源隔离机制：对于GPU这类需要独占使用的设备资源，调度器必须实现严格的隔离机制，防止任何可能的资源冲突。

总结

Volcano调度器中的GPU资源重复分配问题源于对GPU数量资源记录的不完整。通过修改资源记录逻辑，使其同时处理GPU内存和GPU数量两种资源类型，我们成功解决了这一问题。这一修复不仅解决了具体的问题，也增强了调度器对各种GPU资源请求类型的支持能力，为后续更复杂的GPU调度场景打下了坚实基础。