Оркестрация распределенных ИИ-нагрузок#

Данная ИИ-функция автоматизирует запуск и управление распределенными нагрузками искусственного интеллекта (AI) и машинного обучения (ML), которые требуют совместного запуска группы взаимозависимых задач на нескольких узлах кластера: она имитирует когнитивные способности человека, связанные с планированием и координацией выполнения множества параллельных задач, — позволяет атомарно планировать группы pod, организовывать их совместный запуск (gang scheduling), координировать распределенный инференс и обучение моделей, а также восстанавливать группы pod при сбоях:

Сценарий позволяет пользователю:

  • проверять готовность планировщика Volcano и контроллера LWS (LeaderWorkerSet);

  • оркестрировать пакетные (batch) AI/ML-нагрузки средствами Volcano с атомарным планированием группы задач (gang scheduling);

  • управлять очередями и приоритетами планирования распределенных нагрузок средствами Volcano;

  • организовывать многоузловой (multi-node) инференс LLM-моделей с помощью LWS (LeaderWorkerSet);

  • координировать совместное планирование групп pod LWS с внешним планировщиком через gang-планирование.

Примечание

При использовании ИИ-функций DropApp соблюдайте правила работы пользователя с ИИ-функциями.

Предусловия#

Предварительными условиями выполнения сценария являются:

  • Развернутый кластер DropApp с установленным программным компонентом K8S Artificial Intelligence (K8SI).

  • Доступ к кластеру с правами, достаточными для просмотра состояния узлов, pod и пользовательских ресурсов, а также для создания/удаления pod и пользовательских ресурсов оркестрации;

  • Наличие GPU-узлов и настроенного GPU-стека (драйверы NVIDIA, Container Toolkit, K8s-device-plugin), обеспечивающего доступ к ресурсу nvidia.com/gpu.

  • Установленный планировщик Volcano с созданной очередью по умолчанию.

  • Установленный контроллер LWS (LeaderWorkerSet) и зарегистрированный пользовательский ресурс LeaderWorkerSet.

Сведения о Volcano и его установке приведены в разделе «Volcano» Руководства администратора. Информация о LWS — в разделах «LWS» Руководства по установке DropApp с помощью Dactl и «LeaderWorkerSet» Руководства администратора. Установка LWS выполняется по умолчанию с компонентом AI-inference.

Проверка готовности планировщика Volcano#

Проверьте, что планировщик Volcano развернут в кластере и готов к оркестрации распределенных нагрузок. Volcano — пакетная система планирования для DropApp, которая предоставляет механизмы, отсутствующие в стандартном планировщике: одновременное планирование групп задач (gang scheduling), очереди, приоритеты, вытеснение и управление жизненным циклом пакетных нагрузок AI/ML.

Сценарий проверки готовности Volcano:

  1. Убедитесь, что компоненты Volcano в пространстве имен volcano-system находятся в состоянии Running:

    kubectl get pods -n volcano-system

    Пример вывода:

    NAME                              READY   STATUS    RESTARTS   AGE
volcano-admission-xxxxxxxxx-xxx   1/1     Running   0          10m
volcano-controllers-xxxxxxxxx-xx  1/1     Running   0          10m
volcano-scheduler-xxxxxxxxx-xxx   1/1     Running   0          10m

    Компоненты Volcano (vc-controller-manager, vc-scheduler, vc-webhook-manager) запущены и готовы к обработке нагрузок.

  2. Убедитесь, что пользовательские ресурсы Volcano зарегистрированы в кластере:

    kubectl get crd jobs.batch.volcano.sh

    kubectl get crd queues.scheduling.volcano.sh

    kubectl get crd podgroups.scheduling.volcano.sh

    Если в выводе команд присутствуют пользовательские ресурсы jobs.batch.volcano.sh, queues.scheduling.volcano.sh и podgroups.scheduling.volcano.sh, планировщик Volcano готов к оркестрации распределенных нагрузок.

  3. Проверьте, что очередь планирования по умолчанию доступна:

    kubectl get queue default

    Очередь default создается при установке Volcano и используется для планирования нагрузок, которым не назначена явная очередь.

Оркестрация распределенной нагрузки через Job#

Оркестрируйте распределенные AI/ML-нагрузки средствами Volcano, описывая их с помощью пользовательского ресурса Job. Задание Volcano состоит из набора задач (tasks), каждая из которых содержит шаблон pod и количество реплик. Volcano планирует все pod задания совместно, ожидая, пока для размещения всех задач не появится достаточно ресурсов в кластере (одновременное gang-планирование).

Сценарий оркестрации распределенной нагрузки:

  1. Создайте задание Job, содержащее группу взаимозависимых задач. Пример манифеста задания, состоящего из задачи с тремя репликами:

    apiVersion: batch.volcano.sh/v1alpha1
kind: Job
metadata:
  name: ai-training
spec:
  minAvailable: 3
  schedulerName: volcano
  queue: default
  policies:
    - event: PodEvicted
      action: RestartJob
  tasks:
    - replicas: 3
      name: worker
      template:
        spec:
          containers:
            - name: main
              image: sberlinux
              command: ["bash", "-c"]
              args: ["sleep infinity"]
              resources:
                limits:
                  nvidia.com/gpu: "1"
          restartPolicy: OnFailure

    Где:

    • minAvailable — минимальное количество pod, которые должны быть запланированы совместно (при gang-планировании), прежде чем запустится хотя бы один из них;

    • schedulerName — имя планировщика, управляющего размещением задания (volcano);

    • queue — имя очереди планирования, в которую помещается задание;

    • tasks — перечень задач задания, каждая из которых содержит количество реплик (replicas), имя (name) и шаблон pod (template);

    • nvidia.com/gpu — количество физических GPU, необходимых каждому pod.

  2. Примените манифест:

    kubectl apply -f - <<EOF
apiVersion: batch.volcano.sh/v1alpha1
kind: Job
metadata:
  name: ai-training
spec:
  minAvailable: 3
  schedulerName: volcano
  queue: default
  policies:
    - event: PodEvicted
      action: RestartJob
  tasks:
    - replicas: 3
      name: worker
      template:
        spec:
          containers:
            - name: main
              image: sberlinux
              command: ["bash", "-c"]
              args: ["sleep infinity"]
              resources:
                limits:
                  nvidia.com/gpu: "1"
          restartPolicy: OnFailure
EOF

  3. Убедитесь, что все pod задания созданы и запущены совместно:

    kubectl get pods -l job-name=ai-training

    Пример вывода:

    NAME                     READY   STATUS    RESTARTS   AGE
ai-training-worker-0     1/1     Running   0          2m
ai-training-worker-1     1/1     Running   0          2m
ai-training-worker-2     1/1     Running   0          2m

    Все pod задания ai-training запущены совместно, что подтверждает оркестрацию распределенной нагрузки средствами Volcano.

  4. Просмотрите состояние задания Volcano:

    kubectl get job ai-training

    Если в статусе задания указано, что все его задачи выполнены или находятся в процессе выполнения, задание оркестрировано корректно.

  5. После завершения проверки удалите задание:

    kubectl delete job ai-training

Управление очередями и приоритетами планирования#

Volcano поддерживает очереди планирования, объединяющие нагрузки с общими гарантиями ресурсов и приоритетом. Очереди позволяют изолировать ресурсы между группами задач и управлять их планированием. Пользовательские ресурсы Queue задают квоты и лимиты на ресурсы, а PodGroup объединяет группу pod задания для совместного планирования.

Примечание

При создании задания Volcano пользовательский ресурс PodGroup создается автоматически и привязывается к нему. Создавать PodGroup вручную для задания Volcano не требуется.

Сценарий управления очередями и приоритетами:

  1. Создайте очередь с гарантированной квотой на ресурсы GPU:

    apiVersion: scheduling.volcano.sh/v1beta1
kind: Queue
metadata:
  name: ml-team
spec:
  reclaimable: false
  weight: 1
  capability:
    nvidia.com/gpu: "2"

    Где:

    • reclaimable — признак того, что ресурсы очереди могут быть перераспределены другим очередям при простое (false — ресурсы не перераспределяются);

    • weight — вес очереди при распределении ресурсов;

    • capability — максимальный объем ресурсов, доступных очереди.

  2. Примените манифест:

    kubectl apply -f - <<EOF
apiVersion: scheduling.volcano.sh/v1beta1
kind: Queue
metadata:
  name: ml-team
spec:
  reclaimable: false
  weight: 1
  capability:
    nvidia.com/gpu: "2"
EOF

  3. Убедитесь, что очередь создана:

    kubectl get queue ml-team

    Очередь ml-team готова к планированию распределенных нагрузок с ограничением на ресурсы GPU.

  4. Создайте задание Volcano, назначив ему очередь из щагов выше в поле queue. При этом все pod задания планируются совместно в пределах квоты очереди.

  5. Для управления приоритетами нагрузок используйте классы приоритетов Kubernetes, назначая их pod заданий через поле priorityClassName в шаблоне pod. Задания с более высоким приоритетом планируются в первую очередь, а при нехватке ресурсов Volcano может вытеснять низкоприоритетные нагрузки.

Организация многоузлового инференса с LWS#

Организуйте многоузловой (multi-node) инференс LLM-моделей с помощью LWS (LeaderWorkerSet). LeaderWorkerSet позволяет управлять группой pod «лидер + рабочий» как единой репликационной единицей, что необходимо, когда большая LLM-модель шардируется и запускается на нескольких GPU/узлах.

Примечание

Хотя сценарий многоузлового инференса с LWS детально описан в разделе «LLM-инференс (Large Language Model Inference)» настоящего документа, в рамках оркестрации распределенных ИИ-нагрузок он рассматривается как часть координации распределенного инференса.

Сценарий организации многоузлового инференса через LWS:

  1. Убедитесь, что пользовательский ресурс LeaderWorkerSet зарегистрирован в кластере:

    kubectl get crd leaderworkertsets.leaderworkerset.x-k8s.io

    Если в выводе команды присутствует пользовательский ресурс leaderworkertsets.leaderworkerset.x-k8s.io, контроллер LWS готов к управлению группами pod.

  2. Убедитесь, что ограничения на планирование групп pod корректны. Для многоузлового инференса настройте топологию размещения группы pod через конфигурацию LWS таким образом, чтобы pod группы размещались на разных GPU-узлах.

  3. Разверните рабочую нагрузку инференса, описанную с помощью LeaderWorkerSet. Пример манифеста группы pod:

    apiVersion: leaderworkerset.x-k8s.io/v1
kind: LeaderWorkerSet
metadata:
  name: llm-inference
spec:
  replicas: 1
  leaderWorkerTemplate:
    size: 2
    workerTemplate:
      spec:
        containers:
          - name: sglang
            image: <sglang_image>
            ports:
              - containerPort: 30000
                name: http
            resources:
              limits:
                nvidia.com/gpu: 1

    Где:

    • replicas — количество реплик группы pod;

    • size — размер группы pod (количество экземпляров контейнера в группе);

    • workerTemplate — шаблон рабочих pod группы;

    • nvidia.com/gpu — ресурс GPU, запрашиваемый каждым pod группы.

  4. Примените манифест:

    kubectl apply -f - <<EOF
apiVersion: leaderworkerset.x-k8s.io/v1
kind: LeaderWorkerSet
metadata:
  name: llm-inference
spec:
  replicas: 1
  leaderWorkerTemplate:
    size: 2
    workerTemplate:
      spec:
        containers:
          - name: sglang
            image: <sglang_image>
            ports:
              - containerPort: 30000
                name: http
            resources:
              limits:
                nvidia.com/gpu: 1
EOF

  5. Убедитесь, что все pod группы созданы и запущены:

    kubectl get pods -l leaderworkerset.sigs.k8s.io/name=llm-inference

    Пример вывода:

    NAME                  READY   STATUS    RESTARTS   AGE
llm-inference-0-0     1/1     Running   0          2m
llm-inference-0-1     1/1     Running   0          2m

    Pod группы запущены совместно, что подтверждает оркестрацию многоузлового инференса средствами LWS.

  6. После завершения проверки удалите группу pod:

    kubectl delete leaderworkerset llm-inference

Координация планирования групп pod LWS с внешним планировщиком#

Координируйте совместное (gang) планирование групп pod LWS с внешним планировщиком (например, Volcano или YuniKorn), чтобы группа pod размещалась в кластере атомарно. Для этого в конфигурации LWS настраивается параметр gangSchedulingManagement, связывающий группу pod с внешним планировщиком.

Примечание

Параметр gangSchedulingManagement конфигурации LWS описан в разделе «LWS» Руководства по установке DropApp с помощью Dactl. Пустое значение параметра отключает gang-планирование групп pod LWS.

Сценарий координации планирования групп pod:

  1. Убедитесь, что в конфигурации LWS задан параметр gangSchedulingManagement, связывающий группы pod с внешним планировщиком (например, Volcano). Корректное значение параметра обеспечивает атомарный запуск всех pod группы.

  2. Убедитесь, что внешний планировщик (например, Volcano) развернут в кластере и готов к планированию (подробнее — в разделе «Проверка готовности планировщика Volcano»).

  3. Разверните нагрузку с помощью LeaderWorkerSet. Все pod группы размещаются в кластере совместно только при появлении достаточных ресурсов для всей группы.

  4. Убедитесь, что pod группы созданы и запущены совместно:

    kubectl get pods -l leaderworkerset.sigs.k8s.io/name=llm-inference

    Если все pod группы находятся в состоянии Running, координация gang-планирования группы настроена корректно.

  5. После завершения проверки удалите группу pod:

    kubectl delete leaderworkerset llm-inference

Результат#

Ожидаемым результатом являются:

  • готовность планировщика Volcano и контроллера LWS (LeaderWorkerSet) к оркестрации распределенных ИИ-нагрузок;

  • оркестрация распределенной нагрузки средствами Volcano с атомарным планированием группы задач;

  • успешная настройка очередей и приоритетов планирования;

  • организация многоузлового инференса LLM-моделей средствами LWS;

  • скоординированность совместного gang-планирования групп pod с внешним планировщиком.