Topology-aware scheduling with PodGroup and DRA
Kubernetes PodGroup scheduling now treats the group as runtime state rather than a property tucked inside a template. The static Workload object holds the scheduling template, while the PodGroup carries the live scheduling policy and status. Pods link to the runtime group through spec.schedulingGroup, which is a much cleaner boundary than the older workload reference path.
That split matters because the scheduler no longer has to infer group intent from the template object. It can read the PodGroup directly, sort the queued members, and run one decision against one cluster snapshot. That avoids the usual mess where one Pod gets a node and the next one turns the whole placement into dead code.
Keep the runtime group separate from the static Workload template
The Workload template describes the shape of the group. The PodGroup is the thing the scheduler acts on. Mixing those two roles would make every retry awkward, since the scheduler needs current queue state, current minCount, and current status, not just a static template from a controller.
That separation also gives controllers a sane hand-off point. The Job controller creates the workload object, while the PodGroup becomes the active unit of scheduling. If a new Pod turns up later, it joins the live group cycle rather than mutating the template logic. The template stays boring, which is usually what you want from infrastructure.
Follow the queue, snapshot, and minCount checks in kube-scheduler
The scheduler keeps queued group Pods together and evaluates them from a single cluster snapshot. That is the key bit. If the scheduler used separate snapshots or stepped through the Pods one by one, a gang could partly reserve resources and then deadlock itself on the next pass.
minCount is the hard gate. A gang with minCount: 4 only binds if four Pods can run at once. If the cluster cannot place enough of them, the whole PodGroup goes back to the queue and tries again after backoff. The scheduler does not unassign or evict already placed Pods just because the remaining group fails later. That leaves a clean but occasionally awkward edge case: a partially satisfied group can sit there looking close, while still being unschedulable as a whole.
Where topology and Dynamic Resource Allocation change the placement model
Topology-aware scheduling makes the group viable on real nodes, not just in a tidy theoretical cluster. If the group needs a certain spread, or needs to avoid placing all members in one place, the scheduler has to test those constraints against the whole gang, not each Pod in isolation. That reduces the chance of landing on a node set that looks valid until the last member arrives and ruins the pattern.
Dynamic Resource Allocation changes the same story in a quieter way. A PodGroup can carry ResourceClaimTemplate support so claim creation lines up with group scheduling. That matters when the Pod needs more than a CPU and a memory request. The scheduler has to see the claims as part of the placement cycle, or the gang can bind to nodes that cannot satisfy the attached resource path.
Use topology-aware scheduling to keep the group viable on real nodes
Topology-aware scheduling is only useful if it matches the actual cluster layout. A valid gang placement on paper can still fail if the nodes that satisfy one part of the group break the next part. That is a normal failure mode for heterogeneous groups and for groups with inter-Pod dependencies. The scheduler can do the right thing and still have no legal answer.
The practical control is simple: treat node shape, locality, and spread as part of gang viability, not as a bonus check after placement. Once the group is bound, the scheduler is not going back to tidy up the mess for you.
Wire ResourceClaimTemplate into PodGroup so DRA fits the same cycle
Resource claims need to move with the PodGroup, not trail behind it. If a gang depends on DRA, the claim template needs to belong to the same scheduling cycle so the scheduler sees the claim pressure while it decides placement. Otherwise the group may look schedulable until the resource layer says no.
This is the sort of integration that saves one kind of failure and creates another if it is half-finished. Claims that arrive outside the gang cycle can leave the group stuck in queue churn, with no obvious node fault to point at. The scheduler is not being difficult on purpose. It is just refusing to pretend that missing claims do not matter.
Watch workload-aware preemption and Job controller hand-off at the edges
Workload-aware preemption sits at the boundary between “almost fits” and “not happening”. If a gang cannot be placed, preemption may decide whether there is a legal path in at all. The limit is that preemption still has to respect the group model. It cannot quietly fix a bad gang shape by tearing apart already placed Pods in a way that breaks the whole set.
Job controller hand-off matters for the same reason. The controller defines the workload, but the runtime PodGroup is what the scheduler uses. If that hand-off is messy, the result is a group that looks managed while behaving like two separate systems. That tends to end badly, usually at the least convenient time.
