Volcano调度器中多InfiniBand集群资源分配的技术挑战与解决方案

背景与问题描述

在Kubernetes集群中管理多个InfiniBand(IB)网络集群时，我们面临一个特殊的调度需求：确保属于同一个PodGroup的所有Pod都被调度到同一个IB集群内的节点上。这种需求源于高性能计算场景下对网络通信性能的特殊要求，跨IB集群的Pod间通信会显著降低网络性能。

现有解决方案分析

目前可以通过开发Volcano调度器插件来实现这一需求。基本思路是在调度器的predicate阶段实现以下逻辑：

1. 从Session中获取任务所需的最小可用副本数(minAvailable)
2. 根据节点标签构建集群映射表{cluster_name: [nodes]}
3. 筛选出节点数≥minAvailable的IB集群
4. 随机选择一个符合条件的集群
5. 对于每个待调度节点，检查是否属于选定的集群

这种方法虽然可行，但存在两个明显缺陷：

• 随机选择集群的方式在大规模环境中效率低下
• 无法感知其他插件(如资源检查、污点容忍等)对节点的过滤结果

技术挑战深入探讨

插件执行顺序问题

调度器中各插件的predicate函数执行顺序不确定，导致我们无法准确知道其他插件已经过滤了哪些节点。如果简单地按节点标签筛选集群，可能会选中一个表面上节点充足但实际上已被其他插件过滤掉大部分节点的集群。

递归调用风险

理论上，一个插件可以通过遍历Session中的predicate函数来模拟其他插件的过滤行为。但这种做法会导致潜在的递归调用问题：如果多个插件都尝试获取彼此的过滤结果，就会形成无限递归。

专家建议的解决方案

理想方案：修改allocate动作

最合理的解决方案是修改调度器的allocate动作逻辑，使其能够：

1. 遍历所有节点组(IB集群)
2. 基于完整的predicate结果选择最优集群
3. 确保该集群能容纳所有任务

这种方案需要基于现有调度框架进行扩展，实现全局最优的集群选择策略。

临时解决方案：插件执行顺序控制

作为过渡方案，可以通过调整插件配置确保IB集群插件最后执行：

1. 在调度器配置中将该插件置于插件列表末尾
2. 假设前面插件执行完毕后，剩余节点都是可调度的
3. 在此基础上进行集群选择

虽然这种方法不够完美，但在中小规模环境中可以作为一种实用解决方案。

实施建议

对于需要实现类似功能的开发者，建议：

1. 优先考虑修改allocate动作的全局调度逻辑
2. 如果必须使用插件方式，确保合理配置插件执行顺序
3. 避免插件间直接查询彼此的过滤结果，防止递归问题
4. 对于大规模集群，考虑实现确定性的集群选择算法而非随机选择

通过以上方法，可以在Volcano调度器中有效管理多IB集群环境下的Pod调度需求，确保应用获得最佳的网络性能。