driver/kubernetes: skip terminating pods when choosing a pod - #3997
Open
chagui wants to merge 1 commit into
Open
driver/kubernetes: skip terminating pods when choosing a pod#3997chagui wants to merge 1 commit into
chagui wants to merge 1 commit into
Conversation
Signed-off-by: Guilhem Charles <guilhem.charles@gmail.com>
crazy-max
approved these changes
Aug 5, 2026
crazy-max
left a comment
Member
There was a problem hiding this comment.
LGTM thanks!
PTAL @AkihiroSuda
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
We noticed in our production environment that some builds are routed to terminating pods. A build routed to such a pod is killed mid-flight when the grace period expires, and the client doesn't fail fast in that case, so it hangs until the caller's own timeout (Refs #556). In CI that means the job burns its whole time budget instead of failing and retrying elsewhere.
Even with recent fixes for #556 we would benefit from not sending builds to terminating pods in the first place.
ListRunningPodscurrently filters onpod.Status.Phasealone. A pod marked for deletion keepsPhase=Runningfor its entire termination grace period, so it stays selectable right up until its containers are killed. Our set-up configure a preStop hook with a 900secs grade period for thebuildkitdcontainer.Skipping pods with a
DeletionTimestampmatches how upstream Kubernetes decides set membership:IsPodActiveinpkg/controller/controller_utils.gopairs the phase checks withDeletionTimestamp == nil. This doesn't close the race entirely, since a pod can be deleted between theListand the exec, but it shrinks the window from minutes to sub-second.Added unit tests for the pod filtering and both pod choosers; the package had none.
Repro / testing
Setup:
Create a Dockerfile which takes some time, eg.:
Start a build and leave it running. This keeps one pod busy, which is what makes it linger later: GracefulStop waits for the in-flight Solve instead of exiting on SIGTERM.
docker buildx build --builder kindbuilder --progress=plain -f Dockerfile .Once step1 starting appears, find the busy pod and delete only that one. Delete an idle pod instead and buildkitd exits immediately, so nothing lingers.
Now run a second build and look at the candidate list.
Note: I used a custom binary with log statement patched to Info level because the debug level was not reliable.
Before, the terminating pod is a valid candidate:
With this PR, against the same three pods: