Repository navigation
[release-0.20] pod: don't build a new group Workload from terminating pods - #17501
Conversation
A pod group's Workload is built from its pods, with each PodSet template copied from a pod's spec. A pod that is being deleted but is still bound to a node counts as runnable, so it can be picked. Its spec still holds the earlier admission: nodeName, the flavor's node labels and the TAS hostname nodeSelector. The new Workload then fits only that node, and a multi-node gang can never be admitted. This happens when the group's Workload is deleted and replacement pods arrive while the old pods are still in their grace period. The FinalizeTerminatingPodGroups gate only acted when every pod of the group was terminating, so it missed groups that mix old and new pods. With FinalizeTerminatingPodGroups enabled, building a new group Workload now also leaves out the pods that are being deleted on a node: Kueue removes their finalizer, and they do not count toward the group size, shape the PodSets, own the Workload or get its events. The check is for a non-zero deletionTimestamp, since the bug happens during the grace period, while the timestamp is still in the future. Replacement accounting for an existing Workload is unchanged. Once that Workload exists, the old pods still count as excess for it, and removeExcessPods expected an event for each of them. A pod that is already being deleted and has lost Kueue's finalizer is neither patched nor deleted, so no event came and the group's pods stayed gated until the old pods were gone. removeExcessPods now marks such a pod as observed right away, as finalizePods already does. This part is not gated. Signed-off-by: Hao Zhu <zhuhaoangus@gmail.com>
Load used the first listed pod to represent a pod group, and that pod can be one that is being deleted. Building a new group Workload then switched to a live pod, but only inside that build. The cache lists pods in no fixed order, so other reconciles, and the earlier steps of the same reconcile, could still read a terminating pod. For example, an old pod with another queue-name label could rewrite the queue of the Workload that was built from the live pods. With FinalizeTerminatingPodGroups enabled, Load now picks a pod that is not being deleted whenever the group has one. The switch in dropTerminatingPods is no longer needed and is removed. Signed-off-by: Hao Zhu <zhuhaoangus@gmail.com>
✅ Deploy Preview for kubernetes-sigs-kueue ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. 🗂️ Base branches to auto review: 1
Please check the settings in the CodeRabbit UI or the ⚙️ Run configuration
You can disable this status message by setting the Use the checkbox below for a quick retry:
Comment |
|
/lgtm |
|
LGTM label has been added. DetailsGit tree hash: 470a8dbf9727522537c03526b0ab451c884b1f49 |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: k8s-infra-cherrypick-robot, mimowo The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
31b6231
into
kubernetes-sigs:release-0.20
This is an automated cherry-pick of #17454
/assign mimowo
/kind bug