Kubernetes для оркестрації GPU: керування кластерами з тисячами GPU
Оновлено 8 грудня 2025 року
Оновлення грудня 2025: Dynamic Resource Allocation (DRA) у Kubernetes 1.31+ тепер у статусі GA, що забезпечує детальне партиціонування GPU та time-slicing. NVIDIA GPU Operator 24.6+ додає підтримку Blackwell та покращене керування MIG. Kueue (нативна черга завдань Kubernetes) досягає виробничої зрілості для AI-навантажень. Run:ai та CoreWeave демонструють кластери з 50 000+ GPU на Kubernetes. Інструменти мультикластерної федерації (Liqo, Admiralty) забезпечують крос-хмарну оркестрацію GPU. Підтримка vGPU покращується для мультитенантних inference-розгортань.
OpenAI оркеструє 25 000 GPU у кількох кластерах Kubernetes для навчання моделей GPT, використовуючи кастомні оператори, які автоматично обробляють відмови GPU, перебалансовують навантаження в реальному часі та підтримують 97% утилізації, незважаючи на апаратні збої, що відбуваються в середньому кожні 2,5 години.¹ Інфраструктурна команда компанії виявила, що стандартний Kubernetes виходить з ладу приблизно на 5 000 вузлах без суттєвих модифікацій, що змусило їх впровадити ієрархічну кластерну федерацію, кастомні алгоритми планування та GPU-aware автомасштабування, яке розглядає кожен H100 вартістю $30 000 як цінний ресурс, що потребує індивідуального відстеження. Керування GPU у масштабі принципово відрізняється від оркестрації CPU — відмова GPU під час розподіленого навчання може призвести до втрати мільйонів на обчислювальний час, тоді як погане планування, що розділяє GPU, з'єднані через NVLink, спричиняє 8-кратне зниження продуктивності. Організації, що успішно оркеструють тисячі GPU на Kubernetes, повідомляють про на 35% кращу утилізацію, на 60% швидший час розгортання та на 90% зменшення операційних накладних витрат порівняно з керуванням на голому залізі.²
Kubernetes домінує в оркестрації контейнерів з 88% частки ринку, але підтримка GPU з'явилася пізно і залишається складною у масштабі.³ NVIDIA GPU Operator, запущений у 2019 році, нарешті приніс керування GPU корпоративного рівня в Kubernetes, забезпечивши такі функції, як динамічна установка драйверів, автоматичне розгортання device plugin та моніторинг справності GPU. Організації, що запускають AI-навантаження на Kubernetes, повинні орієнтуватися в конфігураціях device plugin, правилах node affinity, топологічно-обізнаному плануванні та квотах ресурсів, які запобігають монополізації GPU окремими командами. Проте ті, хто опановує Kubernetes для оркестрації GPU, отримують можливість розглядати тисячі GPU як єдиний програмований пул ресурсів, досягаючи показників утилізації та операційної ефективності, неможливих з традиційними HPC-планувальниками.
Архітектура GPU device plugin
Фреймворк device plugin у Kubernetes забезпечує виявлення GPU, розподіл та моніторинг справності по всьому кластеру:
NVIDIA GPU Device Plugin слугує основним інтерфейсом між Kubernetes та GPU NVIDIA.⁴ Plugin працює як DaemonSet на кожному GPU-вузлі, реєструючи GPU як планувальні ресурси з kubelet. Під час ініціалізації plugin запитує NVIDIA Management Library (NVML) для виявлення доступних GPU, їх обсягу пам'яті, обчислювальної спроможності та топології з'єднань. Plugin оголошує GPU планувальнику Kubernetes, використовуючи назву ресурсу nvidia.com/gpu, дозволяючи подам запитувати GPU через стандартні специфікації ресурсів.
Процес реєстрації Device Plugin: 1. Plugin запускається та виявляє локальні GPU через NVML 2. Реєструється з kubelet через Unix-сокет за адресою /var/lib/kubelet/device-plugins/ 3. Оголошує доступні GPU з унікальними ідентифікаторами пристроїв 4. Реалізує RPC Allocate() для призначення GPU контейнерам 5. Моніторить справність GPU та повідомляє про збої kubelet 6. Обробляє очищення GPU під час завершення роботи пода
Підтримка Multi-Instance GPU (MIG) дозволяє партиціонувати GPU A100 та H100 на ізольовані екземпляри.⁵ Кожен MIG-екземпляр відображається як окремий GPU для Kubernetes, дозволяючи детальний розподіл ресурсів. Device plugin керує профілями MIG, обробляючи створення, видалення та призначення екземплярів. Організації досягають 7-кратного покращення утилізації GPU шляхом партиціонування недовикористаних GPU для менших навантажень. Конфігурація MIG вимагає ретельного планування, оскільки режими партиціонування неможливо змінити без вивільнення вузлів.
Альтернативні Device Plugin забезпечують різноманітність вендорів: - AMD Device Plugin підтримує GPU з підтримкою ROCm, такі як MI250X - Intel Device Plugin керує GPU Intel та прискорювачами Gaudi - Xilinx FPGA Device Plugin оркеструє ресурси FPGA - Google TPU Device Plugin для кластерів GKE
Стратегії планування для GPU-навантажень
Ефективне планування GPU максимізує утилізацію, зберігаючи продуктивність:
Gang Scheduling гарантує, що завдання розподіленого навчання отримують усі запитані GPU одночасно. Без gang scheduling часткове виділення ресурсів спричиняє deadlock — завдання чекають вічно на решту GPU, які ніколи не стають доступними. Плагіни планувальника Kubernetes, такі як Volcano та Apache YuniKorn, реалізують gang scheduling через PodGroups.⁶ Завдання вказують мінімальні вимоги до GPU, і планувальник або виділяє всі ресурси, або ставить усе завдання в чергу. Gang scheduling знижує утилізацію кластера на 10-15%, але запобігає голодуванню навчальних завдань.
Topology-Aware Scheduling оптимізує розміщення GPU на основі апаратних з'єднань. GPU, з'єднані через NVLink, досягають пропускної здатності 600 ГБ/с порівняно з 32 ГБ/с через PCIe.⁷ Планувальник досліджує топологію вузла для розміщення пов'язаних подів на GPU зі швидкими з'єднаннями. NVIDIA GPU Feature Discovery маркує вузли інформацією про топологію, що дозволяє встановлювати правила affinity. Погані рішення щодо топології спричиняють 3-8-кратне зниження продуктивності для навантажень з інтенсивною комунікацією. Топологічна обізнаність стає критичною при роботі з понад 8 GPU на завдання.
Bin Packing проти Spreading: Bin packing консолідує навантаження на меншій кількості вузлів, покращуючи локальність кешу та зменшуючи мережевий трафік. Spreading розподіляє роботу по вузлах для кращої стійкості до відмов та теплового керування. Оптимальна стратегія залежить від характеристик навантаження — навчальні завдання виграють від bin packing, тоді як inference віддає перевагу spreading. Динамічні стратегії адаптуються на основі утилізації кластера та суміші навантажень.
Priority та Preemption: Виробничі навантаження отримують вищий пріоритет, ніж завдання розробки. Планувальник витісняє поди з нижчим пріоритетом, коли ресурсів бракує. Ретельна конфігурація пріоритетів запобігає блокуванню виробничого inference дослідницькими завданнями. Checkpointing при витісненні гарантує, що прогрес навчання не втрачається. Класи пріоритетів варіюються від system-critical (1000000) до development (100).
Fair Sharing та Quotas: Квоти ресурсів запобігають монополізації GPU однією командою. Ієрархічні квоти забезпечують ліміти на рівні організації з підквотами для окремих команд. Планування fair share забезпечує справедливий розподіл ресурсів з часом. Користувачі, які споживають менше ресурсів, накопичують кредити для майбутнього пікового використання. Системи черг, такі як Kueue, забезпечують чергування завдань зі складним контролем допуску.
Міркування щодо масштабування
Масштабування Kubernetes до тисяч GPU вимагає архітектурних модифікацій:
Обмеження розміру кластера: Окремі кластери Kubernetes підтримують максимум 5 000 вузлів до того, як продуктивність etcd почне деградувати.⁸ Навантаження на API-сервер зростає квадратично зі зростанням кількості вузлів через механізми watch. Цикли узгодження controller manager сповільнюються понад 1 000 вузлів. Network policies стають громіздкими у масштабі. Більшість організацій обмежують кластери до 500-1 000 GPU-вузлів для операційної стабільності.
Мультикластерна федерація: Великі розгортання використовують кілька кластерів Kubernetes, керованих через федерацію. Admiralty або Virtual Kubelet забезпечують крос-кластерне планування. GitOps-інструменти, такі як Flux або ArgoCD, синхронізують конфігурації між кластерами. Технології service mesh забезпечують крос-кластерну мережу. Федерація додає складності, але дозволяє горизонтальне масштабування за межі обмежень одного кластера.
Ієрархічне керування ресурсами: Організуйте кластери ієрархічно з керуючими кластерами, що контролюють робочі кластери. Керуючі кластери запускають компоненти control plane та логіку планування. Робочі кластери розміщують GPU-поди без складних контролерів. Ієрархічний дизайн зменшує радіус ураження при збоях. Чітке розділення відповідальностей спрощує усунення несправностей.
Custom Resource Definitions (CRDs) для AI-навантажень: - TrainingJob: Визначає специфікації розподіленого навчання - InferenceService: Керує розгортаннями для обслуговування моделей - GPUPool: Представляє логічні групування GPU - Checkpoint: Обробляє збереження стану навчання - ModelVersion: Відстежує ітерації моделей та походження
Оптимізації продуктивності для масштабу: - Вимкніть невикористовувані admission webhooks для зменшення затримки API - Реалізуйте pod topology spread constraints для рівномірного розподілу - Використовуйте локальний SSD для образів контейнерів, уникаючи мережевого вузького місця - Увімкніть CPU manager для гарантованого виділення CPU - Налаштуйте huge pages для вимог до пам'яті великих моделей
Моніторинг та спостережуваність
Комплексний моніторинг запобігає мільйонним втратам через простій GPU:
NVIDIA Data Center GPU Manager (DCGM) надає GPU-специфічні метрики, недоступні через стандартний моніторинг Kubernetes.⁹ DCGM експортує понад 100 метрик, включаючи утилізацію SM, пропускну здатність пам'яті, температуру, споживання енергії та помилки ECC. Інтеграція з Prometheus забезпечує довгострокове зберігання метрик та оповіщення. Дашборди Grafana візуалізують продуктивність GPU по всьому парку. Кастомні оповіщення виявляють недовикористані GPU, теплове throttling та деградацію обладнання до того, як станеться збій.
Ключові метрики GPU для моніторингу Kubernetes: - GPU Utilization: Відсоток активних SM (ціль >90%) - Memory Utilization: Виділена пам'ять GPU порівняно з доступною - Power Draw: Фактичне споживання порівняно з TDP, що вказує на throttling - Temperature: Температура GPU та пам'яті - PCIe Bandwidth: Швидкість передачі даних до/від GPU - NVLink Traffic: Пропускна здатність комунікації між GPU - Training Metrics: Криві loss, норми градієнтів, learning rates - Inference Metrics: Запитів на секунду, P99 затримка, розміри batch
Distributed Tracing відстежує запити через кілька GPU та вузлів. Інструментація OpenTelemetry захоплює час кроків навчання, затримку завантаження даних та тривалість checkpoint. Jaeger або Tempo забезпечують зберігання та аналіз розподілених трейсів. Кореляція між трейсами та метриками виявляє вузькі місця продуктивності. Наскрізна видимість зменшує середній час вирішення на 70%.
Агрегація логів централізує логи з тисяч GPU-подів. Fluentd або Fluent Bit збирають логи контейнерів з мінімальними накладними витратами. Elasticsearch зберігає логи з автоматичною індексацією та політиками збереження. Kibana забезпечує пошук та аналіз логів по всьому кластеру. Структуроване логування з консистентними форматами спрощує усунення несправностей. Оповіщення про патерни помилок, що вказують на системні проблеми.
Introl розгортає та керує кластерами Kubernetes для оркестрації GPU по всій нашій глобальній зоні покриття, з експертизою масштабування до 10 000+ GPU-розгортань.¹⁰ Наші команди платформного інжинірингу впровадили кастомні оператори та покращення планування для оптимальної утилізації GPU.
Патерни виробничого розгортання
Архітектура навчального кластера в Anthropic: - Масштаб: 4 000 GPU у 8 кластерах Kubernetes - Топологія: Ієрархічна федерація з центральним планувальником - Сховище: Розподілена файлова система Lustre для навчальних даних - Мережа: Fabric RoCE v2 з 200 Гбіт/с на вузол - Планування: Кастомний gang scheduler з топологічною обізнаністю - Моніторинг: DCGM + Prometheus з інтервалом збору 15 секунд - Результат: 94% утилізації GPU, 50% зменшення часу навчання
Inference-платформа в Uber: - Навантаження: 500 мільйонів прогнозів щодня - Інфраструктура: 2 000 GPU T4 у 20 регіонах - Оркестрація: Kubernetes з Knative для serverless - Автомасштабування: Предиктивне масштабування на основі патернів трафіку - Балансування навантаження: Envoy proxy з маршрутизацією за найменшою затримкою - Оптимізація: Кешування моделей зменшує холодний старт до 2 секунд - Результат: 65% зменшення витрат порівняно з попередньою архітектурою
Гібридне Training-Inference в Spotify: - GPU: 3 000 змішаного парку V100/A100/T4 - Планування: Time-sliced sharing для розробки - Ізоляція: Kata containers для мультитенантної безпеки - Cos
[Контент скорочено для перекладу]
