Kubernetes 1.37: gang scheduling появился в ядре, но включать его придётся вручную

28 августа Tech Times вынес в заголовок сразу две новости: бету gang scheduling в Kubernetes 1.37 и «экономию на простое GPU по умолчанию». За день этот заголовок разошёлся по лентам. Через одиннадцать дней авторы функции написали в блоге проекта: «Все перечисленные здесь бета- и альфа-функции по умолчанию выключены; их нужно включать вручную». 

В этом расхождении между заголовком и первоисточником — вся суть релиза. Группу подов впервые описали в 2018 году и тогда же решили реализовать вне ядра Kubernetes. Следующие восемь лет функцию развивали Volcano, YuniKorn, Kueue и отдельные плагины. В Kubernetes 1.37 групповое размещение стало бетой в kube-scheduler, но по умолчанию оно выключено.

Некоторые обзоры называют бету включённой. Из этого легко сделать вывод, что внешний планировщик больше не нужен. Но KEP передаёт ядру только размещение группы. Очереди и квоты по-прежнему остаются задачей Kueue и Volcano — это прямо указано в документе.

Инженерам здесь пригодится разбор работы кластера с GPU и внешним планировщиком. Администраторам платформы — список feature gates, которые нужно открыть пользователям. Руководителям — критерии, по которым можно решить, стоит ли после обновления отказываться от Volcano. В каждом разделе указано, для кого он предназначен.

Коротко о главном

1. Что нового. В релиз вошли три бета-функции под двумя feature gates: групповое размещение, групповое вытеснение и общий ResourceClaim для группы. Также появились две новые альфа-функции и три изменения, которые могут сломать обновление с 1.36.

2. Приоритеты. Сначала проверьте три изменения, из-за которых компоненты могут не запуститься. Затем разберитесь с GenericWorkload и групповым вытеснением. DRA-бета нужна тем, кто делит устройства между подами; альфы пока стоит оставлять для стенда.

3. Чего ждали и что получили. Эксплуатанты рассчитывали, что после появления gang scheduling в ядре внешний планировщик станет не нужен. В Kubernetes вошло только размещение группы, а очереди и квоты остались за внешними планировщиками по замыслу KEP.

4. Неожиданное. Job больше не получает gang автоматически. Авторы соседнего KEP называют прежнюю интеграцию «fundamentally insufficient», а DRA feature gate теперь нужно включать и на kubelet.

5. Что говорят в сети. Сообщество хвалит единый API, но критикует выключенный по умолчанию feature gate и Cluster Autoscaler, который пока не учитывает группы. Четыре издания неверно указали статус функции или версию API.

6. Админам публичного облака. В managed Kubernetes feature gates открывает провайдер. Объекты v1alpha2 находятся в клиентских кластерах, поэтому решение о доступности беты становится частью продукта платформы.

Что нового

Групповое размещение

Кому: инженеру

Возьмём пул из восьми GPU и две задачи, каждой из которых требуется по восемь подов. kube-scheduler с первых версий размещает поды по одному — для веб-сервиса это нормальный порядок. Но первая задача может успеть занять пять GPU, а вторая — три. Обе ждут недостающих ресурсов, обе удерживают уже выделенные карты, и ни одна не выполняет вычисления.

Хеба Элайоти из Microsoft, соавтор функции, описывает эту ситуацию арифметически: пять размещённых подов из шести дают «0% useful progress plus 83% resource occupancy». Счёт за GPU при этом приходит полностью.

Проект начал закрывать эту проблему в декабре 2025 года, выпустив альфа-версию Workload API в Kubernetes 1.35. В 1.36 API переписали: Workload стал шаблоном, PodGroup — отдельным объектом, а v1alpha1 удалили. Бету планировали выпустить в 1.36, но перенесли на 1.37.

Альфа в 1.35 опиралась на барьеры PreEnqueue и Permit. Авторы KEP пишут, что такая схема не решала проблем с производительностью, livelock и частичным вытеснением.

В 1.37 Workload и PodGroup перешли в scheduling.k8s.io/v1beta1 под feature gate GenericWorkload (CHANGELOG 1.37). Под ссылается на группу через поле spec.schedulingGroup.podGroupName, а в очередь планировщика попадает PodGroup целиком и оценивается за один цикл. Порог задаёт minCount: если удаётся разместить хотя бы столько подов, группа запускается. Если ресурсов для группы не хватает, по документации ни один под из неё не привязывается к ноде.

apiVersion: v1
kind: Pod
metadata:
  name: trainer-0
spec:
  schedulingGroup:
    podGroupName: training-job-a

minCount в 1.36 был неизменяемым, в 1.37 его можно менять на живой группе. Политику basic или gang выбирают один раз, при создании.

Для пула из восьми GPU это означает, что дедлок можно устранить без плагина и без смены schedulerName. У группового размещения появился и единый словарь: по тексту KEP, до 1.37 функцию реализовали за пределами kube-scheduler «как минимум четыре раза», причём каждый раз использовали собственный API.

Для владельца GPU это разница между картой, которая числится занятой, и картой, которая действительно выполняет работу. По отчёту Cast AI за апрель 2026 года средняя утилизация GPU в неоптимизированных кластерах составляет около 5%. Это общая оценка вендора оптимизации, которая учитывает все причины простоя. Частичное размещение — лишь одна из них.

Групповое вытеснение

Кому: инженеру.

Вернёмся к тому же пулу, куда пришла задача с приоритетом выше. Вытеснение по приоритету работало по подам: вытеснили один под из восьми, а семь остались занимать карты без результата. Инженеры Red Hat описали побочный эффект. Автоскейлер видит висящие поды, поднимает ноды, а первые восемь подов «are useless without the full “gang”».

Workload-aware preemption (KEP-5710) стал бетой и влился в тот же GenericWorkload. Группа ищет место сразу под все свои поды и вытесняет чужие за один проход. Как уходят вытесняемые, решает их disruptionMode: режим all освобождает карты целиком, режим по умолчанию single уводит поды по одному. Кстати, обычное вытеснение по приоритету в 1.37 тоже читает disruptionMode, в 1.36 оно его не видело. GA намечен на 1.39.

По CHANGELOG (#139980) вытеснение теперь делает одну попытку сразу со всеми кандидатами. Разработчики пишут: «significantly improves performance but can result in a less optimal choice of preemption victims».

Получается, для групп с disruptionMode: all вытеснение освобождает карты всей группы за один шаг. Режим по умолчанию single, так что all задают явно. Кластеру, где обучение и инференс делят один пул, групповое вытеснение нужно сразу после самого gang.

Общий ResourceClaim на группу

Кому: инженеру. админу платформы.

Классический KEP-3063 для Dynamic Resource Allocation вышел в альфе в Kubernetes 1.26, но позже его отозвали. До stable в 1.34 дошла другая модель — structured parameters из KEP-4381.

Устройство, выделенное через ResourceClaim, могут совместно использовать несколько подов. Каждый из них занимает отдельную запись в status.reservedFor, а всего таких записей может быть не более 256. KEP-5729 прямо называет этот предел ограничением для продакшена: «Для нагрузок производственного масштаба нужно, чтобы один claim могли использовать больше подов».

В 1.37 запись в reservedFor может ссылаться на PodGroup, поэтому одной записи достаточно для всей группы. Функция стала бетой под feature gate DRAWorkloadResourceClaims, который по умолчанию выключен.

Для инженера это снимает ограничение на размер группы, совместно использующей одно устройство. Для администратора платформы важнее другое: feature gate нужно включить в четырёх компонентах — kube-apiserver, kube-controller-manager, kube-scheduler и kubelet. Среди гейтов этого релиза только он применяется на нодах, поэтому после обновления control plane придётся перекатывать и ноды.

Альфы: две новые, две с 1.36

Кому: инженеру.

В Kubernetes 1.36 группы с ролями и топологией существовали только во внешних API: PodGang у Grove и PodGroup у KAI. В пересказах Kubernetes 1.37 часто упоминают четыре альфа-функции, но по описанию feature gates новых среди них только две.

• CompositePodGroup (KEP-6012) описывает иерархию групп: на каждом уровне действует собственный gang и могут применяться отдельные политики вытеснения. Функция рассчитана на дезагрегированный инференс, где prefill и decode работают как разные роли. Альфа API доступен в v1alpha3.

• PodGroupPreemptionPolicy позволяет выбрать режим вытеснения для PodGroup. При значении Never группа не инициирует групповое вытеснение.

• WorkloadWithJob (KEP-5547) остаётся альфой с 1.36. В 1.37 под тем же feature gate добавили KEP-6089 с контроллерными API и библиотекой workloadbuilder.

• TopologyAwareWorkloadScheduling (KEP-5732) тоже остаётся альфой с 1.36. В 1.37 для него добавили метрики, а выход беты перенесли на 1.38.

Альфа-функции показывают, в каком направлении API будет развиваться к 1.38 и 1.39. Манифесты с CompositePodGroup уже можно проверять на стенде.

В мае в блоге VK Tech вышел перевод материала NVIDIA о дезагрегированном инференсе. Группы с ролями в нём собирали KAI Scheduler и Grove: подходящего объекта в ядре Kubernetes тогда не было. В 1.37 плоская группа появилась в бете, а группа с ролями — только в альфе. Пока CompositePodGroup не выйдет из альфы, сценарий из этого материала по-прежнему требует внешнего контроллера.

Что проверить перед обновлением до 1.37

Кому: админу платформы.

В 1.36 gang scheduling и групповое вытеснение включались отдельными feature gates, API работал в v1alpha2, а ссылку PodGroup на Workload проверял admission-плагин. В 1.37 всего этого больше нет.

Feature gates GangScheduling и WorkloadAwarePreemption удалены и объединены в GenericWorkload (CHANGELOG, #139520). Если оставить старое имя в --feature-gates, компонент завершится с ошибкой unrecognized feature gate.

Версию scheduling.k8s.io/v1alpha2 удалили целиком. Группы перешли на v1alpha3 и v1beta1; CHANGELOG относит это изменение к разделу ACTION REQUIRED. Объекты v1alpha2 нужно удалить до обновления: конвертации для них нет.

Удалён и альфа admission-плагин из 1.36, который проверял, что PodGroup ссылается на существующий Workload (#139008). Если плагин был включён, его имя нужно убрать из списков admission-плагинов apiserver.

Старые feature gates и admission-плагин не дадут компонентам запуститься. Объекты v1alpha2 останутся в etcd без обслуживаемой версии. Поэтому все три пункта нужно проверить до обновления.

Все шесть feature gates по умолчанию имеют значение false. Остальные пять зависят от GenericWorkload. Если включить зависимый gate без него, компонент не запустится. На kubelet для DRA-беты нужно включать оба feature gates.

Что нового в 1.37:

• Группа из восьми подов на восьми GPU либо запускается целиком, либо не запускается вовсе. Порог задаёт minCount; с 1.37 его можно менять у уже созданной группы.

• Вытеснение в 1.37 учитывает группы. disruptionMode: all нужно задавать явно: по умолчанию используется single.

• Feature gate GenericWorkload выключен по умолчанию. Его нужно включать на apiserver, controller-manager и scheduler. DRA-бета требует также kubelet, а значит — переката нод.

• Старые имена feature gates, объекты v1alpha2 и альфа admission-плагин нужно убрать до обновления, иначе компоненты не запустятся.

• minCount теперь можно менять у уже существующей группы, а политику basic или gang — нельзя. Порог корректируют на ходу, а модель планирования выбирают при создании объекта.

Разворачивайте кластеры Kubernetes с Managed Containers

Автоматизируйте деплой
и снижайте затраты на инфраструктуру
до 60%

Начинать стоит не с включения новых функций, а с проверки совместимости. В Kubernetes 1.37 удалили старые feature gates, API v1alpha2 и альфа admission-плагин. Если не убрать их до обновления, компоненты не запустятся или в etcd останутся объекты без обслуживаемой версии.

После этого можно расставить приоритеты:

• GenericWorkload — главная функция релиза. Она добавляет групповое размещение и устраняет дедлок, при котором несколько задач удерживают части одного пула GPU, но ни одна не может запуститься.

• Групповое вытеснение входит в тот же feature gate. Оно меняет вытеснение по приоритету: планировщик освобождает ресурсы с учётом всей группы, а не отдельных подов.

• DRAWorkloadResourceClaims нужен, если группы совместно используют устройства через DRA. Его потребуется включить не только в control plane, но и на kubelet, поэтому обновление затронет ноды.

• Поведение Job важно для кластеров, где в 1.36 вручную включали WorkloadWithJob: после обновления Job без явной настройки перейдут на обычное планирование. Подробности — в разделе «Неожиданное».

• Альфа-функции пока лучше не включать в продакшене. До выхода беты их место на стенде.

Чего хотели и что получили

Руководителю.

Групповое размещение пришло в Kubernetes после долгой истории внешних планировщиков. В KEP-583 Coscheduling 2018 года впервые описали PodGroup и сразу решили реализовать coscheduling через CRD в kube-batch. Из kube-batch в 2019 году вырос Volcano, который в 2022 году перешёл в инкубатор CNCF.

За это время экосистема расширилась. В мае 2022 года Apache YuniKorn стал проектом верхнего уровня ASF. В октябре Kubernetes представил Kueue — очередь задач, которая оставляет оркестрацию подов существующим стабильным компонентам. В апреле 2025 года NVIDIA открыла KAI Scheduler, ядро Run:ai.

В декабре 2025 года в Kubernetes 1.35 появился альфа Workload API. В 1.36 он перешёл на v1alpha2, а в 1.37 групповое размещение стало бетой.

После появления gang scheduling в Kubernetes может возникнуть простое ожидание: обновить кластер, выключить Volcano и передать всё штатному планировщику. Раздел Non-Goals KEP-4671 говорит обратное. Авторы не планируют добавлять в kube-scheduler справедливое распределение ресурсов и несколько очередей задач: эти функции останутся у Kueue и Volcano. За пределами KEP также оставлены конкуренция нескольких планировщиков, включая возможные дедлоки, и интеграция с автоскейлером. Цель авторов — дать фреймворк и базовые механизмы, а не реализовать законченный алгоритм gang scheduling.

Это не означает, что Volcano нужен каждому кластеру. Gang scheduling у Volcano и YuniKorn — только одна функция среди очередей, приоритетов между командами и справедливого деления общего пула. Немецкий cloudmagazin пишет, что поддержка gang scheduling в ядре снимает проблему частичного старта GPU-задач, но аргументы в пользу квот и fair share остаются прежними.

Решение об отказе от внешнего планировщика стоит принимать по тому, какие его функции используются в кластере помимо gang scheduling.

Для кластера без квот и межкомандной справедливости возможностей ядра может быть достаточно. Внешний планировщик тогда становится дополнительным control plane со своими CRD и релизным циклом. KEP прямо ставит цель сделать gang scheduling доступным «во всех дистрибутивах Kubernetes».

За пределами релиза остаются три ограничения.

• Поддержка KEP-4671 в Cluster Autoscaler пока не реализована. Запрос создали в ноябре 2025 года, а бот-триаж позднее пометил его как заброшенный. Red Hat реализует групповое масштабирование через Kueue и ProvisioningRequest.

• minCount проверяется в момент размещения. Документация оговаривает, что число работающих подов может опуститься ниже этого порога, если поды удалили или вытеснили.

• Для групп с разными требованиями к подам валидное размещение не гарантировано. Документация Kubernetes 1.37 сохраняет это ограничение; оно распространяется и на группы с межподовыми affinity.

Главное:

1. Kubernetes 1.37 умеет размещать группу, но очереди, квоты и справедливое распределение ресурсов остаются за внешними компонентами.

2. Перед отказом от внешнего планировщика нужно составить список его функций, не связанных с gang scheduling, и оценить именно этот остаток.

3. Cluster Autoscaler пока не учитывает группы. Запрос на поддержку существует с ноября 2025 года, но реализации нет.

4. Gang scheduling развивался за пределами ядра восемь лет. Первый бета-релиз в kube-scheduler сам по себе не отменяет Kueue, Volcano или YuniKorn.

Неожиданное: Job больше не получает gang автоматически

Кому: инженеру.

Первым изменение заметит тот, кто пробовал WorkloadWithJob в Kubernetes 1.36. Тогда полностью параллельные индексированные Job при включённом feature gate автоматически получали PodGroup с политикой gang. В 1.37 Job без .spec.scheduling получает политику Basic, то есть поды планируются по одному.

Контроллер при этом по-прежнему создаёт Workload и PodGroup для каждой подходящей Job. Поэтому кластер, где WorkloadWithJob вручную включали в 1.36, после обновления может незаметно потерять групповое размещение. Если включить feature gate в 1.37, Workload и PodGroup будут создаваться и для обычных Job.

spec:
  scheduling:
    schedulingPolicy:
      gang: {}

Так Job явно запрашивает групповое размещение. Значение gang.minCount по умолчанию равно parallelism.

KEP-6089 объясняет, почему автоматическое назначение политики изменили. В 1.36 интеграция создавала PodGroup с жёстко заданной политикой Gang, а авторы KEP сочли этот подход принципиально недостаточным. Документ также описывает риск split-brain: пользователь JobSet может задать директивы планирования в двух местах, и они будут конфликтовать. Поэтому автоматическую интеграцию переработали, а сама поддержка Job осталась в альфе.

Feature gate DRA теперь нужно включать и на kubelet. Раньше гейты группового планирования было достаточно открыть на control plane. Подробности приведены в таблице feature gates в разделе «Что проверить перед обновлением до 1.37».

Kueue обсуждает переход на API ядра, а NVIDIA развивает собственную модель. Kueue рассматривает альфа-гейт WASPodGroups для Kubernetes 1.37 и новее, но KEP пока не принят. Отказ от собственных меток групп в RFC отложен как минимум до GA.

У KAI остаётся собственная PodGroup в scheduling.run.ai/v2alpha2 (issue #1420). Grove использует PodGang, который бэкенды трансляции преобразуют в ресурсы KAI, Volcano или штатного планировщика.

Volcano тем временем расширяет область применения. В марте проект назвал себя «AI-Native Unified Scheduling Platform» и добавил поддержку инференса и агентных нагрузок. При выборе Volcano gang scheduling теперь становится лишь одной из возможностей наряду с очередями, квотами и новыми типами задач.

Как релиз встретили в сообществе

Кому: всем.

Чаще всего хвалят появление единого примитива для группового размещения. Хеба Элайоти пишет о Kueue, что цель здесь — совместная работа компонентов, а не замена одного другим. Одновременно она предупреждает: без удобных контроллеров фрагментация, которую Workload-Aware Scheduling должен был устранить, воспроизведётся уровнем выше. Положительно оценивают и возможность менять minCount, и вытеснение на уровне группы.

Главная претензия — выключенный по умолчанию feature gate. Командам с правилом «в продакшен — только GA» придётся ждать как минимум Kubernetes 1.38. Cloudmagazin напоминает, что в ядре по-прежнему нет квот и справедливого распределения ресурсов. Критику вызывает и альфа-API, который менялся в каждом релизе: от v1alpha1 до v1alpha3.

Sascha Grunert из Red Hat в интервью Network World назвал главной темой релиза переход с iptables на nftables. Gang scheduling в этой статье упомянуто одной строкой.

Автор rack2cloud смотрит на проблему со стороны закупки: «Планирование GPU не создаёт новые мощности, а помогает принудительно использовать имеющиеся». Планировщик распоряжается доступными картами и должен не допускать их простоя.

Статус функции или версию API четыре издания указали иначе, чем в CHANGELOG.

В заголовке Tech Times объединены две разные новости релиза. Слова «by default» относятся к масштабированию HPA до нуля, а не к gang scheduling. В тексте той же статьи функция, напротив, названа выключенной по умолчанию.

Формулировка о том, что группа запускается только при наличии ресурсов для каждого пода, появилась в релизном посте. Затем её повторили cloudmagazin и Linuxiac. По документации порог запуска задаёт minCount, который может быть меньше размера группы.

Флант в обзоре Kubernetes 1.37 сосредоточился на альфа-функциях, поэтому беты в материал не вошли. Сравнения Volcano, Kueue и KAI у Orion soft и Yandex Cloud вышли до появления беты в ядре.

Для админов публичного облака

Кому: админу платформы.

В управляемом Kubernetes control plane и его feature gates контролирует провайдер. Поэтому GenericWorkload включает сама платформа, а решение о доступности бета-функции становится частью её продукта.

GKE выпустил Kubernetes 1.37 в канале Rapid 4 сентября; бета feature gates там можно переключать в alpha-кластерах. AKS планирует preview в сентябре и GA в октябре. В EKS на 21 сентября последней версией остаётся 1.36.

Перед открытием Kubernetes 1.37 клиентам сначала нужно устранить несовместимые изменения, а затем решить, какие возможности платформы будут доступны в managed-кластерах.

• Просканируйте клиентские кластеры на объекты scheduling.k8s.io/v1alpha2. Конвертации для них нет. Удалять клиентские объекты без согласования нельзя, поэтому понадобятся уведомление и срок для миграции.

• Проверьте конфигурации компонентов на удалённые feature gates и admission-плагин.

• Решите, открывать ли бета-функции. GenericWorkload и DRAWorkloadResourceClaims разумно вынести в отдельный профиль кластера для AI-нагрузок, а альфы оставить только для стендов.

• Для DRAWorkloadResourceClaims запланируйте перекат групп нод: этот feature gate нужно включать на kubelet вместе с GenericWorkload.

• Предупредите клиентов, у которых в 1.36 был включён WorkloadWithJob: после обновления Job без явной настройки перейдут на Basic.

• Дополните документацию правилом для клиентов с Volcano или YuniKorn. Два планировщика на одном пуле GPU принимают решения независимо, а KEP-4671 прямо относит эту конкуренцию к Non-Goals. На время миграции пулы нод лучше развести.

• Если внешние планировщики доступны в каталоге дополнений, проверьте их совместимость. Kueue обсуждает поддержку API ядра, а KAI и Grove сохраняют собственные API.

• В мониторинге и скриптах используйте полное имя podgroups.scheduling.k8s.io. У Volcano есть собственный CRD podgroups.scheduling.volcano.sh, поэтому короткое имя podgroup стало неоднозначным.

• Настройте алерт на группы, где число подов ниже minCount. Такая группа удерживает GPU, но не выполняет работу, а клиент продолжает платить за ресурсы.

• Проверьте автоскейлер. Добавлять ноды под неполную группу бессмысленно, а штатный Cluster Autoscaler пока не учитывает группы.

В Cloud Containers, нашем управляемом Kubernetes, миграция групповых нагрузок начинается с версии кластера и списка доступных на ней feature gates. Только после этого можно переходить к манифестам. Пул из восьми GPU у клиента остаётся тем же, что и в начале статьи, и за его простой платит клиент.

Что учесть при обновлении до 1.37:

• До обновления удалите старые имена feature gates, удалённый admission-плагин и объекты v1alpha2.

• Бета-функции включаются вручную на трёх компонентах. DRA-бета требует также kubelet и GenericWorkload.

• Оценивайте внешний планировщик по тем возможностям, которые остаются за пределами gang scheduling.

• В пересказах релиза чаще ошибаются в статусе функции, чем в её назначении, поэтому статус стоит сверять со страницей feature gate.

Версии и ссылки

Релиз Kubernetes 1.37 вышел 26 августа 2026 года. Авторы разобрали новые функции в блоге проекта, а несовместимые изменения собраны в CHANGELOG. Механика описана в документации по gang scheduling и PodGroup. Историю функции в предыдущих релизах можно проследить в обзорах Фланта для 1.35 и 1.36.

Согласно kep.yaml, GA группового размещения запланирован на 1.38, а группового вытеснения — на 1.39. Если график не изменится, путь от черновика KEP-583 до stable займёт восемь лет.