<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Scheduling on SREKubeCraft | Nick Nikolakakis</title><link>https://srekubecraft.io/tags/scheduling/</link><description>Recent content in Scheduling on SREKubeCraft | Nick Nikolakakis</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Tue, 22 Sep 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://srekubecraft.io/tags/scheduling/index.xml" rel="self" type="application/rss+xml"/><item><title>Kubernetes 1.37 Gang Scheduling - The Workload API, a Silently Dropped Field, and Where Preemption Stops</title><link>https://srekubecraft.io/posts/kubernetes-gang-scheduling-workload-api/</link><pubDate>Tue, 22 Sep 2026 00:00:00 +0000</pubDate><guid>https://srekubecraft.io/posts/kubernetes-gang-scheduling-workload-api/</guid><description>&lt;p&gt;You give a four-rank training job a cluster with six GPUs. The scheduler places three ranks, runs out of devices, and leaves the fourth Pending. A second four-rank job arrives and takes the other three. Now six GPUs are allocated, two pods are Pending forever, and zero jobs are training. Nothing is broken. Every pod that could be scheduled was scheduled. That is exactly the problem.&lt;/p&gt;
&lt;p&gt;This is partial-placement deadlock, and until recently Kubernetes had no answer for it in tree. You reached for Volcano, or Kueue, or the coscheduling plugin, and you accepted a second scheduler or a controller that queued work outside the API you already had.&lt;/p&gt;</description></item></channel></rss>