Kubernetes 1.37: Gang Scheduling Integration and Activation Nuances
The release of Kubernetes 1.37 marks a significant milestone: the gang scheduling feature, which enables the grouping of pods for co-location, has been integrated into the core kube-scheduler as a beta function. However, contrary to initial media reports, this feature is disabled by default and requires manual activation.
On August 28, Tech Times published a headline suggesting that both gang scheduling and GPU idle optimization were enabled by default. Eleven days later, the function’s developers clarified in the official project blog that all beta and alpha features in this release are off by default and must be manually enabled. This discrepancy between news headlines and official documentation is a key aspect of this update.
History and Current Status of Gang Scheduling
The concept of grouped pod placement was first described in 2018, and at that time, it was decided to implement it outside the main Kubernetes core. Over the subsequent eight years, this functionality was developed by projects such as Volcano, YuniKorn, Kueue, and various third-party plugins. With the advent of Kubernetes 1.37, gang scheduling has become an internal beta feature of kube-scheduler, but its activation remains at the user’s discretion.
Distinction Between Core and External Schedulers
Some reviews mistakenly suggest that the inclusion of the gang scheduling beta in the core eliminates the need for external schedulers. However, according to the KEP (Kubernetes Enhancement Proposal) document, the Kubernetes core is now responsible only for the placement of pod groups. Queue management and quotas remain the responsibility of external schedulers like Kueue and Volcano. This is explicitly stated in the official documentation.
Recommendations for Various Professionals
- For Engineers: It is advisable to review a detailed analysis of cluster operation with GPUs and an external scheduler to effectively leverage the new capabilities.
- For Platform Administrators: It is crucial to be familiar with the list of feature gates that must be enabled for users to activate gang scheduling.
- For Managers: Criteria are provided to help make an informed decision on whether to discontinue the use of Volcano after the update, considering the new Kubernetes core capabilities.
While the integration of gang scheduling into Kubernetes 1.37’s core is an interesting development, it seems we’re still looking at a fairly complex setup. The article mentions that queue management and quotas remain with external schedulers. This suggests that the ‘simplified’ approach might still involve significant configuration overhead, potentially negating some of the perceived benefits of core integration for many users. I wonder about the actual ease of migration and potential hidden costs in maintaining hybrid scheduling solutions.