Миграция со Slurm на Kubernetes без боли

Миграция с Slurm на Kubernetes

Если вы работали в академических исследованиях или высокопроизводительных вычислениях (HPC), то наверняка знакомы со Slurm. Не случайно он работает на более чем половине суперкомпьютеров из списка Top 500: он проверен временем и нагрузками, предсказуем, а многие ML-инженеры и исследователи познакомились с ним ещё в аспирантуре. Написать sbatch train.sh и наблюдать, как задача попадает на GPU-узел, — это действие становится совершенно привычным после пары сотен повторений.

Но волна генеративного ИИ — от обучения огромных языковых моделей до масштабирования задач тонкой настройки — подталкивает команды инфраструктуры к обновлению стеков. Kubernetes стал де-факто стандартом оркестрации контейнеров, и многие организации стандартизируются на нём для всех рабочих нагрузок, включая AI/ML. Если ваша платформенная команда объявила «мы переходим на K8s», вы, скорее всего, с тревогой ожидаете этого перехода.

Миграция со Slurm на Kubernetes обычно означает переписывание всех скриптов задач, изучение Kubernetes и навигацию в нём, отладку YAML-манифестов и потерю привычного рабочего процесса интерактивной разработки. Но так быть не обязано.

Что делает Slurm удобным

У Slurm есть реальные сильные стороны, на которые ML-команды привыкли полагаться.

Групповое планирование (gang scheduling) по умолчанию. Когда вы запрашиваете 8 GPU на 2 узлах, Slurm выделяет их все сразу или не выделяет вовсе. Это именно то, что нужно распределённому обучению. Нельзя начать тренировочный запуск на 7 GPU и надеяться, что восьмой подтянется позже.

Гарантии ресурсов. Как только задача получила GPU, они принадлежат ей до завершения. Никаких неожиданных вытеснений, никакой борьбы за ресурсы. Для тренировочного запуска, который может стоить тысячи GPU-часов, такая предсказуемость критически важна.

Простые скрипты задач. Пакетный скрипт Slurm — это просто bash-скрипт с несколькими директивами #SBATCH в начале. Никаких сборок контейнеров, никаких YAML-манифестов, никаких конфигураций развёртывания. Написал скрипт — отправил — он работает.

Интерактивная разработка с salloc. Нужно отладить что-то прямо на GPU-узле? salloc --gpus=1 даст вам оболочку. Подключитесь по SSH, запустите код, итерируйте. Этот рабочий процесс глубоко укоренился в реальном ML-исследовании.

Почему переход на K8s даётся тяжело

Платформенные команды любят Kubernetes. Это отраслевой стандарт оркестрации контейнеров, вокруг него выстроена отличная экосистема инструментов, и он чисто интегрируется с облачной инфраструктурой. Поэтому когда команда инфраструктуры говорит «мы стандартизируемся на K8s», с этим решением сложно спорить.

Но для ML-исследователей этот переход — настоящее испытание (подробнее см. AI on Kubernetes Without the Pain):

Сложные манифесты: K8s требует многословных YAML-файлов на десятки строк там, где у Slurm было 6 строк скрипта.
Нет группового планирования: ванильный K8s не понимает потребности распределённого обучения в выделении всех GPU сразу или ни одного.
Интерактивная разработка сломана: нет простого аналога salloc — вместо этого приходится пробрасывать порты, выполнять exec в поды и редактировать YAML.

Сравните простой скрипт Slurm с тем, что пришлось бы писать для Kubernetes.

И это ещё упрощённый вариант. Реальный манифест K8s нередко требует ConfigMap, Secret, PersistentVolumeClaim, ServiceAccount и многого другого. Манифест разрастается до 60+ строк там, где у Slurm было 6.

Хуже того, ванильный Kubernetes не понимает группового планирования. Его стандартный планировщик охотно выделяет ресурсы по мере их появления, что приводит к взаимным блокировкам (deadlock): несколько задач удерживают часть GPU и ждут остальных. Для планирования в стиле HPC нужны дополнительные компоненты — Volcano или Kueue.

А интерактивная разработка? Аналог salloc в Kubernetes — это проброс портов, exec в поды и правки YAML. До «SSH на узел и запускаю Python» — как до луны.

Итеративные рабочие процессы для обучения AI

SkyPilot: простота Slurm на Kubernetes

SkyPilot — это фреймворк с открытым исходным кодом для запуска AI-нагрузок на любой инфраструктуре. Он поддерживает облачные виртуальные машины (AWS, GCP, Azure и многие другие), кластеры Kubernetes и кластеры Slurm. Ключевая идея: единый интерфейс для всех этих бэкендов при сохранении той простоты, которая делала Slurm приятным в использовании.

Для команд, мигрирующих со Slurm на Kubernetes, SkyPilot переносит привычный Slurm-подобный рабочий процесс в K8s — без потери преимуществ, которые даёт Kubernetes. Вы сохраняете простые описания задач и интерактивный рабочий процесс разработки, а ваша платформенная команда получает оркестрацию контейнеров и интеграцию с экосистемой.

Как это работает

Простой YAML в стиле Slurm вместо манифестов K8s

Помните тот манифест Kubernetes Job на 60+ строк? Вот его эквивалент в SkyPilot.

SkyPilot берёт на себя создание подов, выделение ресурсов, настройку контейнера и сетевое взаимодействие. Вы просто описываете, что вам нужно.

Интерактивная разработка, которая действительно работает

Запустите dev-кластер и подключитесь по SSH — так же, как с salloc:

Этот рабочий процесс привычен для ML-исследователей и инженеров: получить GPU-узел, подключиться по SSH (или открыть удалённую сессию разработки в IDE), итерировать код, запускать эксперименты. SkyPilot реализует это на Kubernetes без акробатики с пробросом портов.

SSH-подключение к dev-узлу через SkyPilot

Преимущества K8s тоже остаются

Запуск на Kubernetes через SkyPilot даёт:

Изоляция контейнеров: каждая задача работает в собственном контейнере со своими зависимостями.
Интеграция с экосистемой K8s: мониторинг, логирование и другие инструменты K8s работают как ожидается.

Перенос задач со Slurm на Kubernetes через SkyPilot

Вот сравнение типичной задачи распределённого обучения бок о бок.

Slurm:

#!/bin/bash
#SBATCH --job-name=train
#SBATCH --nodes=2
#SBATCH --gpus-per-node=8

module load cuda/12.1
source ~/venv/bin/activate

srun torchrun \
  --nproc_per_node=8 \
  --nnodes=$SLURM_NNODES \
  --node_rank=$SLURM_NODEID \
  train.py

SkyPilot:

name: train
num_nodes: 2
resources:
  accelerators: H100:8

setup: |
  uv venv .venv
  source .venv/bin/activate
  uv pip install torch transformers

run: |
  source .venv/bin/activate
  torchrun \
    --nproc_per_node=$SKYPILOT_NUM_GPUS_PER_NODE \
    --nnodes=$SKYPILOT_NUM_NODES \
    --node_rank=$SKYPILOT_NODE_RANK \
    train.py

Структура достаточно похожа, чтобы перенос скриптов не вызывал затруднений. Большинство концепций Slurm напрямую отображаются на SkyPilot:

Slurm SkyPilot

Slurm	SkyPilot
Интерактивное выделение (`salloc`)	`sky launch -c dev`
Запуск на существующем кластере	`sky exec <cluster>`
Отправка пакетной задачи	`sky launch`
Просмотр запущенных задач	`sky queue`
Отмена задачи	`sky cancel`
Просмотр доступных ресурсов	`sky show-gpus`

Интерактивное выделение (salloc)

sky launch -c dev

Запуск на существующем кластере

sky exec <cluster>

Отправка пакетной задачи

sky launch

Просмотр запущенных задач

sky queue

Отмена задачи

sky cancel

Просмотр доступных ресурсов

sky show-gpus

Переменные окружения

Переменные окружения Slurm имеют эквиваленты в SkyPilot, например:

Slurm SkyPilot

Slurm	SkyPilot
`SLURM_NNODES`	`SKYPILOT_NUM_NODES`
`SLURM_NODEID`	`SKYPILOT_NODE_RANK`
`SLURM_GPUS_PER_NODE`	`SKYPILOT_NUM_GPUS_PER_NODE`
`SLURM_JOB_ID`	`SKYPILOT_TASK_ID`
`SLURM_NODELIST`	`SKYPILOT_NODE_IPS`

SLURM_NNODES

SKYPILOT_NUM_NODES

SLURM_NODEID

SKYPILOT_NODE_RANK

SLURM_GPUS_PER_NODE

SKYPILOT_NUM_GPUS_PER_NODE

SLURM_JOB_ID

SKYPILOT_TASK_ID

SLURM_NODELIST

SKYPILOT_NODE_IPS

Полный список переменных окружения, поддерживаемых SkyPilot, см. в документации.

Что делать с NFS в Slurm?

Один нюанс, о котором стоит помнить: кластеры Slurm обычно имеют общую домашнюю директорию NFS, смонтированную на всех узлах. В Kubernetes это не происходит автоматически.

Используйте SkyPilot Volumes (рекомендуется): SkyPilot Volumes обеспечивают высокопроизводительное персистентное хранилище (в 10–100 раз быстрее объектного хранилища), оптимизированное для AI-нагрузок. Данные и чекпоинты сохраняются между жизненными циклами кластера, а повторные загрузки данных не нужны. Создайте том и подмонтируйте его в своих задачах.

Тома поддерживают персистентное хранилище для долгосрочных данных, эфемерные тома для временного пространства, а также распределённые файловые системы для многоузлового обучения с одновременным доступом.

Кроме того, можно монтировать существующие NFS-тома, использовать облачные корзины вроде S3 или синхронизировать локальный код через workdir.

Что ещё меняется?

Разделы выше охватывают основной рабочий процесс, однако несколько возможностей Slurm пока не имеют прямых аналогов в K8s.

Маршрутизация по разделам и кластерам (multi-partition / multi-cluster). Разделы Slurm позволяют администраторам делить кластер на пулы оборудования (например, debug, batch, priority) с разными лимитами и приоритетами. В Kubernetes можно настроить несколько K8s-контекстов и выбирать нужный через --infra, но единого планировщика, охватывающего разделы, как в Slurm, здесь нет. На стороне Slurm SkyPilot уже умеет управлять несколькими кластерами Slurm как единым пулом ресурсов с автоматическим переключением при отказе — подробно об этом мы расскажем в отдельной публикации.

Политики fair-share и QOS. Встроенный планировщик Slurm с поддержкой fair-share и уровнями QOS даёт администраторам детальный контроль над тем, кто и когда получает ресурсы. В K8s аналогичные возможности покрывает Kueue.

Советы для плавного перехода

Начните с рабочих процессов разработки. Освойтесь с sky launch -c dev для интерактивной работы, прежде чем мигрировать пакетные задачи обучения. Цикл обратной связи здесь короче, так что всё быстро становится понятным.

Действуйте постепенно. Не обязательно мигрировать всё сразу. SkyPilot может сосуществовать с имеющимся использованием Slurm. Попробуйте на одном проекте, проверьте рабочий процесс, затем постепенно переносите остальные нагрузки.

Используйте дашборд. У SkyPilot есть веб-интерфейс (sky dashboard), который показывает все ваши кластеры и задачи. Он удобен для получения единого обзора ресурсов K8s и запущенных нагрузок. Живую демонстрацию можно посмотреть на demo.skypilot.co.

Дашборд SkyPilot с обзором кластеров и задач

Сначала проверьте доступность GPU. sky show-gpus --infra k8s покажет, что доступно на вашем кластере K8s. Запускайте эту команду перед запуском задач, чтобы понимать доступность ресурсов.

Итог

И у Slurm, и у Kubernetes есть реальные сильные стороны (подробное сравнение см. в Slurm vs Kubernetes for AI Infrastructure). Slurm предлагает простоту и функции, ориентированные на HPC, а Kubernetes — оркестрацию контейнеров и интеграцию с экосистемой. Вопрос не в том, что «лучше», а в том, должны ли вы выбирать между простотой и современной инфраструктурой.

SkyPilot предлагает не выбирать. При переходе со Slurm на Kubernetes вы должны сохранить привычный рабочий процесс и одновременно получить преимущества, которые нужны вашей платформенной команде. Вы описываете задачу, запускаете её и сосредотачиваетесь на исследовании, а не на изучении оркестрации контейнеров.

Если вы готовитесь к миграции на K8s и вас пугает кривая обучения — попробуйте SkyPilot. Быстрый старт займёт около 5 минут, а руководство по настройке Kubernetes поможет подключиться к вашему кластеру.