Изменение ресурсов подов в приостановленных Job: бета в Kubernetes 1.36

В Kubernetes v1.36, выпущенном 27 апреля 2026 года, появилась долгожданная возможность изменять ресурсы подов в шаблоне приостановленного Job — теперь эта функция переведена в бета-версию. Ранее, начиная с версии 1.35, она была доступна как альфа-эксперимент, но теперь становится более стабильной и готовой к использованию в production-средах. Это нововведение упрощает управление пакетными и ML-нагрузками, позволяя динамически корректировать запросы ресурсов без удаления и пересоздания Job.

Суть улучшения проста, но критична для эффективного планирования ресурсов в кластере. Раньше, если очередь или администратор решали, что приостановленный Job должен запуститься с другими ресурсами — например, с меньшим числом GPU из-за нехватки — единственным выходом было удалить Job и создать его заново. Это приводило к потере метаданных, статуса и истории выполнения. Новая возможность позволяет изменить ресурсы прямо в существующем Job, пока он находится в состоянии suspend, что сохраняет все связанные данные и упрощает автоматизацию.

Как работает изменение ресурсов в приостановленном Job

Функция задействует механизм изменяемых полей в spec.template.spec.containers[].resources. Когда Job приостановлен (suspend: true), контроллер очереди или администратор может отправить запрос на обновление ресурсов через API. Например, если изначально Job запрашивал 4 GPU, а свободно только 2, можно уменьшить запрос до 2 GPU и затем возобновить Job. Kubernetes проверит, что Job действительно приостановлен, и применит изменения. После resume Job запустится с новыми ресурсами, при этом все завершённые поды останутся без изменений.

Важно отметить, что изменения возможны только для приостановленных Job. Если Job уже выполняется, ресурсы остаются неизменными. Также поддерживаются любые типы ресурсов: стандартные CPU и память, а также расширенные ресурсы, например GPU от NVIDIA или AMD. Для включения функции в кластере необходимо, чтобы был активирован соответствующий шлюз признаков (feature gate) MutablePodResourcesForSuspendedJobs. В v1.36 он включён по умолчанию, поэтому большинство пользователей смогут воспользоваться нововведением без дополнительных настроек.

Какие проблемы решает эта возможность?

Проблема статичности ресурсов в Job давно беспокоила сообщество. В реальных сценариях пакетной обработки и машинного обучения точные потребности в ресурсах часто неизвестны на момент создания Job. Оптимальное распределение зависит от текущей загрузки кластера, приоритетов очередей и доступности специализированного оборудования. До появления этой функции операторам приходилось либо рисковать, запрашивая ресурсы с запасом, либо пересоздавать Job при каждом изменении, что нарушало автоматизацию и приводило к потере данных.

Разработчики Kueue — популярного контроллера очередей для Kubernetes — активно участвовали в продвижении этой функции. Kueue управляет очередями Job и может динамически корректировать ресурсы перед запуском. Теперь интеграция стала более естественной: Kueue может изменять ресурсы в существующем Job без потери его идентичности. Это особенно ценно для длительных ML-тренировок, где перезапуск с нуля — потеря времени и вычислительных мощностей.

Технические детали: как это реализовано в API

С точки зрения API, изменения затрагивают ресурс Job в группе batch/v1. В spec.template.spec.containers[].resources теперь разрешено изменение полей requests и limits, если Job приостановлен. При этом Kubernetes проверяет, что Job не имеет запущенных подов (поле .status.active == 0). После обновления ресурсов, при возобновлении Job, новый под создаётся с изменёнными спецификациями. Важно: изменения применяются только к будущим подам. Уже завершённые поды остаются без изменений. Также нельзя изменить ресурсы, если Job не приостановлен — API вернёт ошибку.

Для администраторов это означает более гибкое управление ресурсами. Например, если CronJob создаёт Job, который не может стартовать из-за нехватки ресурсов, раньше он просто падал с ошибкой. Теперь можно уменьшить запрос ресурсов для этого конкретного экземпляра, позволив ему прогрессировать медленнее, но без полного отказа. Функция упрощает жизнь операторам: не нужно писать сложные скрипты для удаления и воссоздания Job. Всё делается через стандартный API update.

Кому и как это поможет?

Основные пользователи — команды, эксплуатирующие пакетные нагрузки и ML-пайплайны. Системы автоматического масштабирования очередей, такие как Kueue, Volcano, Run:ai, выиграют от возможности динамически корректировать ресурсы без потери состояния Job. Администраторы кластеров смогут более эффективно использовать ресурсы, не опасаясь, что Job придётся пересоздавать. В российском и СНГ-сегменте, где активно используются Kubernetes для высоконагруженных систем, это нововведение может упростить эксплуатацию ML-платформ и batch-обработки данных. Например, в облачных провайдерах, где ценообразование зависит от типа ресурсов, возможность уменьшить запросы в моменты пиковой нагрузки поможет снизить затраты.

Планы на будущее

Функция остаётся в бета-статусе в v1.36. Ожидается, что в следующих версиях (v1.37 или v1.38) она перейдёт в стабильную (GA). Разработчики Kubernetes также рассматривают возможность расширения изменяемых полей на другие аспекты Job, например, на переменные окружения или аргументы команды. Пока же сообществу предлагается активно тестировать бета-версию и сообщать об ошибках. Это важный шаг к более гибкому и отказоустойчивому управлению пакетными нагрузками в Kubernetes, который устраняет давнюю боль операторов и открывает путь к более интеллектуальным контроллерам очередей.

Итог

Возможность изменять ресурсы подов в приостановленном Job — значительное улучшение для управления пакетными и ML-нагрузками в Kubernetes. Она устраняет необходимость удалять и пересоздавать Job при изменении требований к ресурсам, сохраняя метаданные и историю. С выходом v1.36 эта функция становится доступной для широкого круга пользователей, и мы рекомендуем изучить её возможности уже сейчас.