KEP-4671: Add Workload Aware Scheduling blog post for v1.36#54667
KEP-4671: Add Workload Aware Scheduling blog post for v1.36#54667k8s-ci-robot merged 10 commits intokubernetes:mainfrom
Conversation
|
/sig scheduling |
✅ Pull request preview available for checkingBuilt without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
…urceClaim support in the post
lmktfy
left a comment
There was a problem hiding this comment.
Looks good as a draft, but it's clearly not ready to merge as-is.
| To power this, the `kube-scheduler` features a new *PodGroup scheduling cycle* that enables atomic workload processing | ||
| and paves the way for future enhancements. We are also rolling out the first iterations of *topology-aware scheduling* | ||
| and *workload-aware preemption* to advance the scheduling capabilities for these workloads. Additionally, | ||
| we have added *ResourceClaim support for workloads* to unlock *Dynamic Resource Allocation |
There was a problem hiding this comment.
Does "we" mean:
Maciej Skoczeń (Google),
Antoni Zawodny (Google),
Matt Matejczyk (Google),
Bartosz Rejman (Google),
Jon Huhn (Microsoft),
Maciej Wyrzuc (Google),
TBD
?
If not: reword for clarity.
| completely replacing the previous `v1alpha1` API version. | ||
|
|
||
| In v1.35, Pod groups and their runtime states were embedded within the Workload resource. | ||
| In the new model, the Workload object is rarely updated (as a template object), |
There was a problem hiding this comment.
What part of a Workload is immutable? Can I still set labels?
| minCount: 4 | ||
| ``` | ||
|
|
||
| Next, workload controllers (such as the Job controller) stamp out runtime PodGroup instances based on those templates. |
There was a problem hiding this comment.
Does this mean that if I have a CronJob I could end up having a new Workload created every n minutes? (If so, might be worth calling out the limitation).
|
|
||
| ## Integration with the Job controller | ||
|
|
||
| TBD |
There was a problem hiding this comment.
This part doesn't look ready to merge.
There was a problem hiding this comment.
IMO we should just remove this section.
Job controller will stay alpha in 1.37 anyway for future API changes so I think its okay to skip this update for 1.36.
WDYT @helayoty?
There was a problem hiding this comment.
I think adding a few sentences here would be beneficial, unless the job integration is already documented elsewhere. Since this is our only real controller integration so far, it's likely the easiest way for users to try out WAS.
There was a problem hiding this comment.
There is #54489.
Okay I think its fine to add then.
There was a problem hiding this comment.
Section has been updated and I believe it's ready now. PTAL.
|
LGTM label has been added. DetailsGit tree hash: 1fef3186689baa9f4ce0cf19ff598763a5e46557 |
helayoty
left a comment
There was a problem hiding this comment.
PTAL on the Job integration section sugget.
| AI/ML and batch workloads introduce unique scheduling challenges that go beyond simple Pod-by-Pod scheduling. | ||
| In Kubernetes v1.35, we introduced the first tranche of *workload-aware scheduling* improvements, | ||
| featuring the foundational Workload API alongside basic *gang scheduling* support built on a Pod-based framework, | ||
| and an *opportunistic batching* feature to efficiently process identical Pods. |
There was a problem hiding this comment.
Did we manage to integrate the opportunistic batching for gang-scheduling plugin?
There was a problem hiding this comment.
Opportunistic batching is enabled by default also during gang scheduling as long as the member pods are identical
| `scheduling.k8s.io/v1alpha2` {{< glossary_tooltip text="API group" term_id="api-group" >}}, | ||
| completely replacing the previous `v1alpha1` API version. | ||
|
|
||
| In v1.35, Pod groups and their runtime states were embedded within the Workload resource. |
There was a problem hiding this comment.
I'd state in breif why this was not the good way to follow and why we decoupled PodGroup.
There was a problem hiding this comment.
This paragraph describes that:
This separation also improves performance and scalability as the PodGroup API allows per-replica sharding of status updates.
| * Reaching out via [Slack (#workload-aware-scheduling)](https://kubernetes.slack.com/archives/C0AHLJ0EAEL). | ||
| * Joining the [SIG Scheduling](https://docs.google.com/document/d/13mwye7nvrmV11q9_Eg77z-1w3X7Q1GTbslpml4J7F3A/edit) | ||
| or [Workload API integration](https://docs.google.com/document/d/1XSPdK4L3zkAFhAZ3hBQJr2k7JX9CpGD7NeQfujM1PT4/edit) meetings. | ||
| * Filing a new [issue](https://github.com/kubernetes/enhancements/issues) in the Kubernetes repository. |
There was a problem hiding this comment.
Let's not encourage people to do this; we don't want people to file KEPs without following the recommended process.
There was a problem hiding this comment.
Good catch, I wanted to link a k/k repo
|
LGTM label has been added. DetailsGit tree hash: f9005633b62f4e12bcff8cb95fa4447d0fb64239 |
|
/lgtm |
|
LGTM label has been added. DetailsGit tree hash: c049dc812027db32939b1b4afd746aad73c5b8ad |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: graz-dev 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 |
Description
This PR adds a blog post for Workload Aware Scheduling initiative update for v1.36
Issue
KEP: kubernetes/enhancements#4671