Gang Scheduling

In this KEP, kube-scheduler is modified to support gang scheduling[^1]. We focus on framework support and building blocks, not the ideal gang-scheduling algorithm - it can come as a follow-up. We start with simpler implementation of gang scheduling, kube-scheduler identifies pods that are in a group and waits until all pods reach the same stage of the scheduling/binding cycle before allowing any pods from the group to advance past that point. If not all pods can reach that point before a timeout expires, then the scheduler stops trying to schedule that group, and all pods release all their resources. This allows other workloads to try to allocate those resources. New core types called Workload and PodGroup are introduced to tell the kube-scheduler that a group of pods should be scheduled together and to define policy options related to gang scheduling. Pods may have an object reference in their spec to the PodGroup they belong to. The Workload and PodGroup objects are intended to evolve[^2] via future KEPs to support additional kube-scheduler improvements, such as topology-aware scheduling. The API is structured to decouple template from runtime grouping: - Workload represents a static template defining the scheduling hierarchy and scheduling policy definition that specifies what workload behavior should be applied. - PodGroup becomes a standalone, self-contained runtime scheduling unit for a group of pods that encapsulates both the scheduling policy and status. True workload[^6] owners are responsible for creating PodGroup objects (together with Workload objects). PodGroups are expected to be created based on the podGroupTemplates defined in the Workload. - Pods reference PodGroup which is their immediate execution context.