Изолированные Kubernetes-кластеры на общих GPU с KAI Scheduler и vCluster

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

С другой стороны, попытка разделить один большой кластер между множеством команд порождает хаос: конфликты версий Custom Resource Definitions (CRD), пересечения прав доступа (RBAC) и невозможность гибко распределять вычислительные мощности. В какой-то момент каждая команда начинает требовать собственный кластер, чтобы просто не мешать друг другу. Но есть ли путь посередине? Оказывается, да. Современная экосистема Kubernetes предлагает мощное комбинированное решение, позволяющее сохранить полную логическую изоляцию для каждой команды, при этом физически разделяя один и тот же пул GPU-ресурсов. В этой статье мы подробно разберем архитектуру, использующую KAI Scheduler и vCluster, и покажем, как реализовать этот паттерн на практике.

01Проблема масштабируемости и изоляции в AI-инфраструктуре

Запуск выделенного Kubernetes-кластера для каждой команды часто дает больше изоляции, чем реально требуется организации. С одной стороны, один общий кластер может успешно обслуживать множество команд, но по мере роста числа участников координационные издержки растут экспоненциально. Основные боли, с которыми сталкиваются DevOps и MLOps-инженеры, включают:

• Конфликты CRD: Разные команды могут использовать разные версии кастомных ресурсов, что приводит к конфликтам в едином пространстве имен API.
• Пересечение RBAC: Сложно настроить права доступа так, чтобы одна команда не могла случайно (или намеренно) повлиять на работу другой.
• Отсутствие гранулярного квотирования GPU: В стандартном Kubernetes сложно «вырезать» точный объем GPU-мощности для команды, особенно если речь идет о дробных долях видеопамяти или вычислительных блоков.

На определенном масштабе команды начинают требовать собственные кластеры просто для восстановления автономии. Однако физическое разделение оборудования — это шаг назад в эффективности. Решение, которое мы рассмотрим, сохраняет автономность команд, не разделяя аппаратную часть. Оно базируется на едином control plane кластера с общим пулом GPU, механизме разделения GPU с квотами на уровне команд и изолированных Kubernetes-контрольных плоскостях для каждой команды, включающих собственный API-сервер, контроллеры, хранилище данных, синхронизатор и планировщик.

02Архитектурные компоненты: KAI Scheduler и vCluster

Для реализации этой модели используются два мощных open-source инструмента, которые дополняют друг друга как никогда раньше. Давайте разберем каждый из них.

KAI Scheduler: Интеллектуальное планирование GPU

KAI Scheduler — это надежный, эффективный и масштабируемый планировщик Kubernetes, aware-aware к топологии, который был специально разработан для оптимизации распределения GPU-ресурсов для задач искусственного интеллекта. В отличие от стандартного kube-scheduler, KAI Scheduler понимает, что GPU — это не просто «еще один CPU», а ресурс с уникальными характеристиками: памятью, вычислительными ядрами и возможностью совместного использования (sharing).

Он предназначен для управления крупномасштабными GPU-кластерами, включающими тысячи узлов, и поддерживает высокую пропускную способность рабочих нагрузок. Ключевая особенность KAI Scheduler — возможность динамического распределения GPU-ресурсов. Он может работать параллельно с стандартным kube-scheduler. Любой под (pod), в спецификации которого указан schedulerName: kai-scheduler, будет обрабатываться KAI Scheduler. Все остальные поды продолжают проходить через обычный процесс планирования. Это позволяет внедрять KAI Scheduler постепенно, без необходимости переписывать всю инфраструктуру.

vCluster: Виртуализация контрольной плоскости

vCluster — это платформа Kubernetes, которая предоставляет полностью изолированные tenant-кластеры на вашей инфраструктуре или напрямую на bare-metal железе. Каждая tenant-кластер получает свой собственный API-сервер, пользовательские определения ресурсов (CRD) и контроль доступа на основе ролей (RBAC). Для пользователя это выглядит как полноценный, выделенный Kubernetes-кластер, хотя физически он делит узлы и оборудование с другими.

Виртуализированная контрольная плоскость невидима для пользователей (tenants): нет общих узлов control plane, нет агентов внутри кластера, которые могли бы создать боковые пути (lateral paths) между средами. Это делает vCluster идеальным выбором для GPU-инфраструктуры, где командам нужен собственный чистый опыт работы с кластером без физического разделения оборудования. В данном руководстве используется модель shared-nodes от vCluster, где команды делят GPU-узел, но каждая получает свою изолированную контрольную плоскость. Это оптимально подходит для доверенных внутренних команд. Для недоверенных арендаторов, требующих разделения на уровне узлов, сети и хранения, тот же паттерн расширяется до модели vCluster private nodes.

03Сценарий использования: Три команды, одна видеокарта

Чтобы проиллюстрировать работу системы, мы рассмотрим пример с тремя командами:

1. NLP Team (Команда обработки естественного языка): Хочет устанавливать свои собственные CRD для специфичных задач NLP.
2. Vision Team (Команда компьютерного зрения): Требует прав cluster-admin для отладки планирования и оптимизации запросов.
3. Recommender System Team (Команда рекомендательных систем): Работает на другой версии Kubeflow, что делает совместное использование единого пространства имен невозможным.

Никто из них не хочет делить контекст kubectl и случайно сломать среду друг друга. Используя vCluster, каждая команда получает свою изолированную контрольную плоскость, RBAC, пространства имен и CRD. Они могут иметь доступ cluster-admin. Под капотом все tenant-кластеры делят одни и те же узлы и GPU.

04Практическая реализация: Пошаговое руководство

Демонстрация запускается на GPU-инстансе NVIDIA Brev в облаке Nebius. Для воспроизводимости и наглядности используется кластер с одной видеокартой NVIDIA L40S (48 ГБ VRAM), 40 vCPU и 160 ГБ оперативной памяти. Операционная система — Ubuntu 24.04.4 LTS. В качестве дистрибутива Kubernetes выбран MicroK8s версии 1.36.2, который был предварительно настроен Brev, включая аддон gpu-addon, устанавливающий NVIDIA GPU Operator в пространство имен gpu-operator-resources.

Важное примечание: для других сред (GKE, EKS, AKS, vanilla k8s, k3s) шаги создания кластера и установки GPU Operator будут отличаться. Однако шаги с 3 (установка KAI Scheduler) onward идентичны для любого Kubernetes, где запущен NVIDIA GPU Operator с включенным Container Device Interface (CDI).

Шаг 1: Локальные инструменты

Сначала установите standalone kubectl и helm, чтобы избежать префикса microk8s перед каждой командой. Затем настройте kubeconfig и зафиксируйте версию MicroK8s, чтобы snap не обновлял control plane во время демонстрации.

sudo snap refresh --hold microk8s
sudo snap install kubectl --classic --channel=1.35/stable
sudo snap install helm --classic
mkdir -p ~/.kube
sudo microk8s config > ~/.kube/config
sudo chown $USER:$USER ~/.kube/config
chmod 600 ~/.kube/config

Убедитесь, что необходимые аддоны MicroK8s включены:

microk8s enable dns
microk8s enable hostpath-storage    # vCluster требует PVC

Проверьте состояние узлов и классов хранения:

kubectl get nodes -o wide
kubectl get storageclass

Шаг 2: Добавление Helm-репозитория

Добавьте официальный Helm-репозиторий NVIDIA:

helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
helm repo update

Шаг 3: Подтверждение работы GPU Operator

Проверьте, что поды NVIDIA GPU Operator запущены:

kubectl get pods -n gpu-operator-resources

Если вы используете старую версию GPU Operator, обновите ее до версии 26.3.x:

helm upgrade gpu-operator nvidia/gpu-operator \
   -n gpu-operator-resources \
   --version v26.3.3 \
   --reset-then-reuse-values

Если GPU Operator не установлен, установите его напрямую:

helm install gpu-operator nvidia/gpu-operator \
    -n gpu-operator-resources --create-namespace \
    --version v26.3.3 \
    --set driver.enabled=false \
    --set operator.defaultRuntime=containerd \
    --set toolkit.env[0].name=CONTAINERD_CONFIG \
    --set toolkit.env[0].value=/var/snap/microk8s/current/args/containerd.toml \
    --set toolkit.env[1].name=CONTAINERD_SOCKET \
    --set toolkit.env[1].value=/var/snap/microk8s/common/run/containerd.sock \
    --set-string toolkit.env[2].name=CONTAINERD_SET_AS_DEFAULT \
    --set-string toolkit.env[2].value=1

Шаг 4: Установка KAI Scheduler

Установите KAI Scheduler:

helm upgrade -i kai-scheduler \
  oci://ghcr.io/kai-scheduler/kai-scheduler/kai-scheduler \
  -n kai-scheduler --create-namespace \
  --version v0.16.4 \
  --set "global.gpuSharing=true"

Проверьте, что поды планировщика запущены:

kubectl get pods -n kai-scheduler

Шаг 5: Определение очередей для команд

KAI Scheduler использует CRD Queue для моделирования иерархии организации → команда. На этом шаге создается один родительский объект (ml-org) с общим бюджетом в один GPU и три дочерние очереди. Каждая команда гарантированно получает 0.33 GPU и может увеличить лимит до полного GPU, если другие команды простаивают.

Сохраните следующий YAML в файл create-queues.yaml:

apiVersion: scheduling.run.ai/v2
kind: Queue
metadata:
  name: ml-org
spec:
  resources:
    gpu: { quota: 1, limit: -1, overQuotaWeight: 1 }
---
apiVersion: scheduling.run.ai/v2
kind: Queue
metadata:
  name: team-nlp
spec:
  parentQueue: ml-org
  priority: 100
  resources:
    gpu: { quota: 0.33, limit: 1, overQuotaWeight: 1 }
---
apiVersion: scheduling.run.ai/v2
kind: Queue
metadata:
  name: team-vision
spec:
  parentQueue: ml-org
  priority: 100
  resources:
    gpu: { quota: 0.33, limit: 1, overQuotaWeight: 1 }
---
apiVersion: scheduling.run.ai/v2
kind: Queue
metadata:
  name: team-recommender
spec:
  parentQueue: ml-org
  priority: 100
  resources:
    gpu: { quota: 0.33, limit: 1, overQuotaWeight: 1 }

Здесь quota — это гарантированный минимум, limit — максимальное разрешенное значение, а overQuotaWeight управляет распределением излишков. Примените конфигурацию:

kubectl apply -f create-queues.yaml
kubectl get queues

Обратите внимание, что default-parent-queue и default-queue создаются автоматически KAI Scheduler при первой установке. Это очереди по умолчанию для любых подов, которые не указывают конкретную очередь.

Шаг 6: Запуск vCluster для каждой команды

Установите CLI для vCluster:

curl -L -o vcluster "https://github.com/loft-sh/vcluster/releases/latest/download/vcluster-linux-amd64"
sudo install -m 755 vcluster /usr/local/bin/vcluster
rm vcluster
vcluster --version

Определите конфигурацию vCluster. Критически важная настройка — setOwner: false. Планировщик KAI Scheduler (pod-grouper) проходит по цепочкам владения (Job → Pod, Deployment → ReplicaSet → Pod) для автоматической группировки рабочих нагрузок. Отключение переписывания владельца vCluster позволяет KAI Scheduler видеть реальную иерархию.

cat > vcluster.yaml <<'EOF'
experimental:
  syncSettings:
    setOwner: false 
sync:
  fromHost:
    nodes:
      enabled: true
      selector:
        all: true
EOF

Создайте один vCluster для каждой команды:

vcluster create team-nlp          --values vcluster.yaml --connect=false
vcluster create team-vision       --values vcluster.yaml --connect=false
vcluster create team-recommender  --values vcluster.yaml --connect=false

Проверьте, что все три vCluster запущены:

vcluster list

Каждая команда видит реальные узлы, включая GPU-узел:

vcluster connect team-nlp -- kubectl get nodes

Шаг 7: Развертывание рабочей нагрузки

Каждая команда развертывает свою GPU-нагрузку из своего vCluster. Спецификация пода проста, но содержит три ключевых поля, указывающих KAI Scheduler, что делать:

vcluster connect team-nlp -- kubectl apply -f - <<'EOF'
apiVersion: v1
kind: Pod
metadata:
  name: nlp-sentiment-model
  labels:
    kai.scheduler/queue: team-nlp # Какая команда
  annotations:
    gpu-fraction: "0.33"          # Сколько GPU
spec:
  schedulerName: kai-scheduler.   # Использовать KAI, а не стандартный
  tolerations:
    - key: nvidia.com/gpu
      operator: Exists
      effect: NoSchedule
  containers:
    - name: nlp-inference
      image: nvidia/cuda:12.4.0-base-ubuntu22.04
      command: ["bash", "-c", "nvidia-smi; sleep infinity"]
  nodeSelector:
    nvidia.com/gpu.present: "true"
EOF

Повторите то же самое для каждой команды, изменив имя очереди. Теперь проверьте результат:

kubectl get pods -A

Три пода, три разных пространства имен vcluster-team-*, все работают на одном физическом узле. Каждая команда видит только свой под изнутри своего vCluster:

vcluster connect team-nlp         -- kubectl get pods -o wide
vcluster connect team-vision      -- kubectl get pods -o wide
vcluster connect team-recommender -- kubectl get pods -o wide

05Что это значит на практике

Описанная архитектура решает фундаментальную проблему современной AI-инфраструктуры: как совместить гибкость и изоляцию, необходимые для продуктивных команд, с жесткой необходимостью экономии ресурсов. Использование KAI Scheduler и vCluster позволяет организациям:

1. Максимизировать утилизацию GPU: Дробное распределение ресурсов (fractional GPU) позволяет запускать множество легких задач на одной карте, избегая простоя.
2. Сохранять автономность команд: Каждая команда имеет свой «кластер», свои права, свои CRD и свои версии ПО, что ускоряет разработку и снижает риски конфликтов.
3. Упростить управление: Единый control plane и единый пул узлов упрощают мониторинг, резервное копирование и обслуживание инфраструктуры.

Для российских специалистов и компаний, работающих с GPU-инфраструктурой, этот подход особенно актуален в условиях ограниченного доступа к облачным ресурсам и необходимости оптимизации имеющегося оборудования. Локальный запуск таких решений на базе open-source компонентов (KAI Scheduler, vCluster, NVIDIA GPU Operator) позволяет строить независимые, безопасные и эффективные AI-платформы без привязки к проприетарным облачным решениям. Это не просто технический трюк, а стратегический шаг к зрелой MLOps-культуре, где инфраструктура служит ускорителем, а не ограничителем для инноваций.

Таким образом, комбинация KAI Scheduler и vCluster предлагает элегантное, масштабируемое и экономически эффективное решение для управления GPU-инфраструктурой в многопользовательской среде. Это позволяет организациям двигаться вперед, не жертвуя ни производительностью, ни безопасностью.

Источник: NVIDIA Developer ↗