[Exception Request] Workload Aware Preemption (KEP-5710)

[Wojciech Tyczyński]

 Hi,

  I'm requesting a code freeze exception for KEP-5710: Workload-Aware Preemption:

Enhancement name: Workload-aware preemption
Enhancement status: Alpha
SIG: SIG Scheduling
k/enhancements repo issue #: 5710
PR #s:

1. Scheduler changes https://github.com/kubernetes/kubernetes/pull/137606 

2. API & integration: https://github.com/kubernetes/kubernetes/pull/136589

Additional time needed (in calendar days, due end of day AoE): 5

 The first PR is already aligned with all approvers (sanposhiho@, macsko@, dom4ha@) and just requires addressing a few remaining details.

 The second PR - API is already approved, only the last integration comments needs deeper review, but is also directionally aligned with approvers.

Reason this enhancement is critical for this milestone:

Workload-Aware Scheduling is critical for running AI workloads on Kubernetes and Workload-Aware Preemption is its critical building block. 

This feature is important to unblock the graduation of the Workload API in 1.37 and allow experimentation of multiple in-progress integrations already happening in the ecosystem.

Risks from adding code late: Low. The feature builds on the Workload API and Gang Scheduling (KEP-4671) which introduced a new "workload-aware" path in the scheduler.  Workload-Aware Preemption is not exercised outside that path, which itself is protected by feature gates.

Risks from cutting enhancement: Existing pod-by-pod preemption is fundamentally incompatible with Workload-Aware Scheduling. Consequently, a clear preemption solution is a blocker for gang-scheduling (a heavily requested and awaited feature) and the Workload API itself.

Multiple ecosystem projects (JobSet, TrainJob, KubeRay, LeaderWorkerSet) are already designing & working on integrations with the Workload API to deliver value from gang-scheduling and subsequent Workload-Aware Scheduling features to their users. 

Lack of this feature in Alpha 1.36 may further delay Gang scheduling feature to Beta in 1.37 and impede overall Kubernetes adoption for AI workloads.

 thanks

wojtek tyczynski

[Dominik Marciński]

+1

WAS Preemption is the missing piece needed to provide a fully usable Workload-Aware Scheduling experience and to graduate the API changes to beta in the next release. Not graduating Workload API on time will delay adoption, which we want to avoid. The feature was already reduced to essential changes.

The PRs are mostly reviewed and accepted by SIG scheduling leads, they just require finishing the code review mainly on the test side.

The changes are flag gated and entirely within scheduling, so there is no risk that other components will be affected.

--
You received this message because you are subscribed to the Google Groups "sig-scheduling" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sig-schedulin...@kubernetes.io.
To view this discussion visit https://groups.google.com/a/kubernetes.io/d/msgid/sig-scheduling/CAPgfqyXG7YjyaCb9mhfhOVcSGzx8%3DxHxD1%2BwurFQ_waTCu5rDg%40mail.gmail.com.

[Kensei Nakada]

+1

As explained, this really is a crucial piece as a Kubernetes community to make Kubernetes ML usecase ready.

Best,

Kensei (@sanposhiho)

2026年3月19日(木) 2:19 'Wojciech Tyczyński' via sig-scheduling <sig-sch...@kubernetes.io>:

--

[Ryota]

Hi all,

The release team is APPROVING this exception request for KEP-5710 based on the discussion in the Slack thread[0].

Given KubeCon EU is taking place in the week of 23rd March, we are accepting longer extension than usual.

Based on the 5 calendar day extension, your updated deadline to merge code + test PRs for this KEP is:

Monday, 23rd March, 2026 (Anywhere-on-Earth) / 12:00 UTC on Tuesday, 24th March, 2026

Thanks,
Ryota Sawada
v1.36 Release Team Lead

[0]: https://kubernetes.slack.com/archives/C2C40FMNF/p1773996853252969