Volcano调度器资源容量计算问题分析

问题背景

Volcano作为一款面向高性能计算场景的Kubernetes批处理调度系统，其核心调度算法对集群资源的管理和分配至关重要。近期在实际使用中发现，Volcano在计算队列真实容量(realCapability)时存在逻辑缺陷，导致调度结果与预期不符，甚至可能引发调度器崩溃。

问题现象

在实际测试环境中，我们配置了一个60核CPU的节点集群和三个不同权重的队列：

1. default队列：权重1，分配0.7核
2. low-priority-queue队列：权重1，保障15核
3. deployment-queue队列：权重88

测试发现两个典型问题场景：

场景一：资源分配超出预期

当在deployment-queue队列中依次创建三个PodGroup时：

1. 1个Pod，请求20核
2. 1个Pod，请求5核
3. 2个Pod，各请求20核

预期结果是前两个PodGroup进入Inqueue状态，第三个Pending。但实际结果是三个PodGroup都进入Inqueue状态，只有当第三个PodGroup请求增加到21核时才会Pending。

场景二：调度器崩溃

在low-priority-queue队列创建PodGroup并占用资源后，再在deployment-queue队列创建多个PodGroup并修改资源请求，会导致调度器状态异常最终崩溃。

问题根源分析

通过分析源代码和测试数据，发现问题主要出在队列realCapability的计算逻辑上：

1. 容量计算未考虑其他队列已分配资源：当前计算仅基于队列自身权重和集群总资源，未扣除其他队列已分配的资源量。例如deployment-queue队列的realCapability应为60-0.7-15=44.3核，但实际计算为45核。

2. 资源分配校验不完整：PodGroup从Pending转为Inqueue的状态判断仅检查队列剩余容量，未全局校验集群实际可用资源。

3. 资源分配溢出导致崩溃：当各队列deserved值总和超过集群总资源时，调度器未做合理处理，导致算术运算异常。

解决方案建议

针对上述问题，建议从以下几个方面进行改进：

1. 改进realCapability计算逻辑：

   • 计算时应扣除其他队列已分配和保障的资源
   • 引入全局资源视图校验机制

2. 增强资源分配校验：

   • 增加集群级资源可用性检查
   • 实现更精确的资源预留机制

3. 完善异常处理：

   • 增加资源分配溢出保护
   • 优化调度器状态恢复机制

总结

Volcano调度器的资源容量计算是调度决策的核心环节，其准确性直接影响整个集群的稳定性和资源利用率。通过深入分析实际使用中遇到的问题，我们发现当前实现存在改进空间。建议用户在使用时注意资源分配策略，并关注后续版本对此问题的修复进展。

对于生产环境用户，建议：

1. 合理设置队列权重和保障资源
2. 监控调度器日志，及时发现异常
3. 考虑使用资源配额等辅助机制控制资源分配