Kubernetes для оркестрації GPU: управління кластерами з тисяч GPU

Оновлено 8 грудня 2025 року

Оновлення грудня 2025: Kubernetes 1.31+ Dynamic Resource Allocation (DRA) тепер загальнодоступний, забезпечуючи детальне розділення GPU та часове розподілення. NVIDIA GPU Operator 24.6+ додає підтримку Blackwell та покращене управління MIG. Kueue (власна для Kubernetes система черг завдань) досягає виробничої зрілості для AI навантажень. Run.ai та CoreWeave демонструють кластери з 50,000+ GPU на Kubernetes. Інструменти федерації мульти-кластерів (Liqo, Admiralty) забезпечують міжхмарну оркестрацію GPU. Підтримка vGPU покращується для мульти-орендних інференс розгортань.

OpenAI оркеструє 25,000 GPU через декілька кластерів Kubernetes для тренування моделей GPT, використовуючи спеціальні оператори, які автоматично обробляють відмови GPU, перебалансовують навантаження в режимі реального часу та підтримують 97% використання попри апаратні відмови, які відбуваються в середньому кожні 2.5 години.¹ Команда інфраструктури компанії виявила, що стандартний Kubernetes руйнується приблизно на 5,000 вузлах без значних модифікацій, змушуючи їх впроваджувати ієрархічну федерацію кластерів, спеціальні алгоритми планування та GPU-свідоме автомасштабування, яке розглядає кожен H100 вартістю $30,000 як цінний ресурс, що потребує індивідуального відстеження. Управління GPU у великому масштабі принципово відрізняється від оркестрації CPU—відмова GPU під час розподіленого тренування може змарнувати мільйони в обчислювальному часі, тоді як погане планування, яке розділяє GPU, з'єднані через NVLink, спричиняє 8-кратне погіршення продуктивності. Організації, які успішно оркеструють тисячі GPU на Kubernetes, повідомляють про 35% краще використання, 60% швидше розгортання та 90% скорочення операційних витрат порівняно з bare-metal управлінням.²

Kubernetes домінує в оркестрації контейнерів з 88% частки ринку, але підтримка GPU з'явилася пізно і залишається складною у великому масштабі.³ NVIDIA GPU Operator, запущений у 2019 році, нарешті приніс корпоративне управління GPU в Kubernetes, забезпечивши такі функції, як динамічна установка драйверів, автоматичне розгортання плагінів пристроїв та моніторинг стану GPU. Організації, які запускають AI навантаження на Kubernetes, повинні навігувати конфігурації плагінів пристроїв, правила афінності вузлів, топологічно-свідоме планування та квоти ресурсів, які запобігають монополізації GPU ресурсів окремими командами. Проте ті, хто опанував Kubernetes для оркестрації GPU, отримують можливість розглядати тисячі GPU як єдиний програмований пул ресурсів, досягаючи рівнів використання та операційної ефективності, неможливих з традиційними HPC планувальниками.

Архітектура плагіну пристрою GPU

Фреймворк плагіну пристрою Kubernetes забезпечує виявлення GPU, виділення та моніторинг стану по кластерах:

NVIDIA GPU Device Plugin служить основним інтерфейсом між Kubernetes та NVIDIA GPU.⁴ Плагін працює як DaemonSet на кожному GPU вузлі, реєструючи GPU як планувальні ресурси з kubelet. Під час ініціалізації плагін запитує NVIDIA Management Library (NVML) для виявлення доступних GPU, їх об'єму пам'яті, обчислювальної здатності та топології interconnect. Плагін рекламує GPU планувальнику Kubernetes, використовуючи назву ресурсу nvidia.com/gpu, дозволяючи подам запитувати GPU через стандартні специфікації ресурсів.

Потік реєстрації плагіну пристрою: 1. Плагін запускається і виявляє локальні GPU через NVML 2. Реєструється з kubelet через Unix сокет в /var/lib/kubelet/device-plugins/ 3. Рекламує доступні GPU з унікальними ID пристроїв 4. Реалізує Allocate() RPC для призначення GPU контейнерам 5. Моніторить стан GPU та повідомляє про відмови kubelet 6. Обробляє очищення GPU під час завершення роботи pod

Підтримка Multi-Instance GPU (MIG) дозволяє розділення A100 та H100 GPU на ізольовані інстанси.⁵ Кожен MIG інстанс з'являється як окремий GPU для Kubernetes, дозволяючи детальне виділення ресурсів. Плагін пристрою керує MIG профілями, обробляючи створення, видалення та призначення інстансів. Організації досягають 7-кратного кращого використання GPU шляхом розділення недовикористаних GPU для менших навантажень. Конфігурація MIG потребує ретельного планування, оскільки режими розділення не можуть змінюватися без дренування вузлів.

Альтернативні плагіни пристроїв забезпечують різноманітність постачальників: - AMD Device Plugin підтримує GPU з ROCm, такі як MI250X - Intel Device Plugin керує Intel GPU та прискорювачами Gaudi - Xilinx FPGA Device Plugin оркеструє ресурси FPGA - Google TPU Device Plugin для кластерів GKE

Стратегії планування для GPU навантажень

Ефективне планування GPU максимізує використання при збереженні продуктивності:

Gang-планування забезпечує отримання усіх запитаних GPU розподіленими тренувальними завданнями одночасно. Без gang-планування часткове виділення ресурсів спричиняє дедлок—завдання чекають вічно на решту GPU, які ніколи не стають доступними. Плагіни планувальника Kubernetes, такі як Volcano та Apache YuniKorn, реалізують gang-планування через PodGroups.⁶ Завдання вказують мінімальні вимоги GPU, і планувальник або виділяє всі ресурси, або ставить все завдання в чергу. Gang-планування зменшує використання кластера на 10-15%, але запобігає голодуванню тренувальних завдань.

Топологічно-свідоме планування оптимізує розміщення GPU на основі апаратних interconnect. GPU, з'єднані через NVLink, досягають пропускної здатності 600ГБ/с проти 32ГБ/с через PCIe.⁷ Планувальник вивчає топологію вузла для розміщення пов'язаних pod на GPU зі швидкими interconnect. NVIDIA GPU Feature Discovery позначає вузли інформацією про топологію, дозволяючи правила афінності. Погані рішення топології спричиняють погіршення продуктивності в 3-8 разів для комунікаційно-важких навантажень. Свідомість топології стає критичною понад 8 GPU на завдання.

Bin Packing проти Spreading: Bin packing консолідує навантаження на меншій кількості вузлів, покращуючи локальність кешу та зменшуючи мережевий трафік. Spreading розподіляє роботу по вузлах для кращої відмовостійкості та теплового управління. Оптимальна стратегія залежить від характеристик навантаження—тренувальні завдання виграють від bin packing, тоді як інференс віддає перевагу spreading. Динамічні стратегії адаптуються на основі використання кластера та поєднання навантажень.

Пріоритет та вимкнення: Виробничі навантаження отримують вищий пріоритет ніж розробницькі завдання. Планувальник вимикає pod нижчого пріоритету, коли ресурси стають дефіцитними. Ретельна конфігурація пріоритетів запобігає блокуванню виробничого інференсу дослідницькими завданнями. Checkpointing вимкнення забезпечує збереження прогресу тренування. Класи пріоритетів варіюються від системно-критичних (1000000) до розробницьких (100).

Справедливий розподіл та квоти: Квоти ресурсів запобігають монополізації GPU окремими командами. Ієрархічні квоти дозволяють загальноорганізаційні обмеження з командно-специфічними під-квотами. Планування справедливого розподілу забезпечує справедливе розподілення ресурсів у часі. Користувачі, які споживають менше ресурсів, накопичують кредити для майбутньої burst потужності. Системи черг, такі як Kueue, забезпечують постановку завдань у чергу з складним контролем доступу.

Міркування масштабування

Масштабування Kubernetes до тисяч GPU вимагає архітектурних модифікацій:

Обмеження розміру кластера: Окремі кластери Kubernetes підтримують максимум 5,000 вузлів до деградації продуктивності etcd.⁸ Навантаження API сервера зростає квадратично з кількістю вузлів через механізми спостереження. Цикли узгодження controller manager уповільнюються понад 1,000 вузлів. Мережеві політики стають важкими в управлінні у масштабі. Більшість організацій обмежують кластери 500-1,000 GPU вузлами для операційної стабільності.

Федерація мульти-кластерів: Великі розгортання використовують декілька кластерів Kubernetes, керованих через федерацію. Admiralty або Virtual Kubelet дозволяють міжкластерне планування. Інструменти GitOps, такі як Flux або ArgoCD, синхронізують конфігурації по кластерах. Технології service mesh забезпечують міжкластерну мережу. Федерація додає складності, але дозволяє горизонтальне масштабування понад обмеження одного кластера.

Ієрархічне управління ресурсами: Організовуйте кластери ієрархічно з управляючими кластерами, що контролюють робочі кластери. Управляючі кластери запускають компоненти control plane та логіку планування. Робочі кластери хостять GPU pod без складних контролерів. Ієрархічний дизайн зменшує радіус ураження відмов. Чітке розділення обов'язків спрощує усунення неполадок.

Custom Resource Definitions (CRDs) для AI навантажень: - TrainingJob: Визначає специфікації розподіленого тренування - InferenceService: Керує розгортаннями подачі моделі - GPUPool: Представляє логічні групування GPU - Checkpoint: Обробляє збереження стану тренування - ModelVersion: Відстежує ітерації та родовід моделі

Оптимізації продуктивності для масштабу: - Вимкнути невикористані webhook'и допуску, зменшуючи затримку API - Реалізувати обмеження розподілу топології pod для рівномірного розподілення - Використовувати локальний SSD для образів контейнерів, уникаючи мережевого вузького місця - Увімкнути менеджер CPU для гарантованого виділення CPU - Налаштувати великі сторінки для вимог пам'яті великих моделей

Моніторинг та спостережуваність

Всебічний моніторинг запобігає простою GPU вартістю в мільйони доларів:

NVIDIA Data Center GPU Manager (DCGM) забезпечує GPU-специфічні метрики, недоступні через стандартний моніторинг Kubernetes.⁹ DCGM експортує 100+ метрик, включаючи використання SM, пропускну здатність пам'яті, температуру, споживання енергії та помилки ECC. Інтеграція Prometheus дозволяє довгострокове зберігання метрик та алертинг. Панелі Grafana візуалізують продуктивність GPU по всьому парку. Спеціальні алерти виявляють недовикористані GPU, теплове throttling та деградацію апаратного забезпечення до виникнення відмов.

Ключові GPU метрики для моніторингу Kubernetes: - Використання GPU: Відсоток активних SM (ціль >90%) - Використання пам'яті: Виділена GPU пам'ять проти доступної - Споживання енергії: Фактичне проти TDP, що вказує на throttling - Температура: Температури GPU та пам'яті - Пропускна здатність PCIe: Швидкості передачі даних до/з GPU - Трафік NVLink: Пропускна здатність міжGPU комунікації - Метрики тренування: Криві втрат, норми градієнтів, швидкості навчання - Метрики інференсу: Запити на секунду, P99 затримка, розміри batch

Розподілене трасування відстежує запити по декільком GPU та вузлам. Інструментація OpenTelemetry захоплює часи кроків тренування, затримку завантаження даних та тривалість checkpoint. Jaeger або Tempo забезпечують зберігання та аналіз розподілених трас. Кореляція між трасами та метриками ідентифікує вузькі місця продуктивності. Наскрізна видимість зменшує середній час вирішення на 70%.

Агрегація логів централізує логи з тисяч GPU pod. Fluentd або Fluent Bit збирають логи контейнерів з мінімальними витратами. Elasticsearch зберігає логи з автоматичним індексуванням та політиками утримання. Kibana дозволяє пошук та аналіз логів по всьому кластеру. Структуроване логування з консистентними форматами спрощує усунення неполадок. Алерти на шаблони помилок, що вказують на системні проблеми.

Introl розгортає та керує кластерами Kubernetes для оркестрації GPU по нашій глобальній зоні покриття, з експертизою масштабування до 10,000+ GPU розгортань.¹⁰ Наші команди платформної інженерії впровадили спеціальні оператори та покращення планування для оптимального використання GPU.

Шаблони виробничого розгортання

Архітектура тренувального кластера в Anthropic: - Масштаб: 4,000 GPU по 8 кластерах Kubernetes - Топологія: Ієрархічна федерація з центральним планувальником - Зберігання: Розподілена файлова система Lustre для тренувальних даних - Мережа: RoCE v2 fabric з 200Gbps на вузол - Планування: Спеціальний gang планувальник з топологічною свідомістю - Моніторинг: DCGM + Prometheus з 15-секундними інтервалами scrape - Результат: 94% використання GPU, 50% скорочення часу тренування

Платформа інференсу в Uber: - Навантаження: 500 мільйонів прогнозів щодня - Інфраструктура: 2,000 T4 GPU по 20 регіонах - Оркестрація: Kubernetes з Knative для serverless - Автомасштабування: Прогнозувальне масштабування на основі шаблонів трафіку - Балансування навантаження: Envoy proxy з маршрутизацією найменшої затримки - Оптимізація: Кешування моделі зменшує холодний старт до 2 секунд - Результат: 65% скорочення витрат проти попередньої архітектури

Гібридне тренування-інференс у Spotify: - GPU: 3,000 змішаний парк V100/A100/T4 - Планування: Часово-розділене використання для розробки - Ізоляція: Kata контейнери для мульти-орендної безпеки - Вартість