Volcano调度器中PodGroup异常删除问题的分析与修复

问题背景

在Kubernetes集群中使用Volcano调度器时，当用户频繁调整Deployment工作负载的副本数（例如在1和0之间反复切换），可能会观察到某些Pod长时间处于Pending状态无法被调度。经过深入分析，发现这是由于Volcano调度器对PodGroup资源的处理逻辑存在缺陷导致的。

技术原理

Volcano调度器通过PodGroup来管理一组相关联的Pod的调度。每个PodGroup代表一个逻辑上的"作业"，调度器会确保满足最小成员数（MinMember）要求的Pod能够被整体调度。当Deployment的副本数被设置为0时，调度器会尝试删除对应的PodGroup；而当副本数恢复为1时，又会创建新的PodGroup。

问题根因

问题的本质在于PodGroup的删除和创建操作之间存在竞态条件：

1. 当副本数从1变为0时，调度器开始删除PodGroup
2. 由于资源释放等操作可能存在延迟，删除可能失败并进入重试队列
3. 在重试间隔期间，如果用户又将副本数从0改为1
4. 此时调度器会创建新的PodGroup，但随后重试机制又会删除这个新建的PodGroup
5. 最终导致新创建的Pod找不到有效的PodGroup而无法被调度

解决方案

修复方案的核心思想是为PodGroup添加版本标识，使调度器能够区分"新创建的PodGroup"和"待删除的旧PodGroup"。具体实现包括：

1. 在删除PodGroup前检查其资源版本(ResourceVersion)
2. 只有当当前缓存中的PodGroup版本与待删除的版本匹配时才执行删除
3. 对于新创建的PodGroup，由于其版本较新，不会被旧的删除操作影响

实现效果

修复后，调度器日志中会明确记录新旧PodGroup的版本信息对比。例如：

oldpgversion:70915324-4b00-416a-99cb-ec4c5cf27b2e
newpgversion:201e5032-6fe0-4f5e-93e9-b4c43c749c08

当版本不匹配时，调度器会跳过删除操作，确保新创建的PodGroup能够正常参与调度。

总结

这个问题的修复保证了Volcano调度器在处理频繁变化的Deployment工作负载时能够正确维护PodGroup生命周期，避免因竞态条件导致的Pod调度失败。对于需要动态调整规模的业务应用，这一改进显著提高了调度系统的稳定性和可靠性。