Kubernetes спростив перехід на DRA: GPU можна розподіляти без переписування Pod

Перехід на новий механізм розподілу GPU у Kubernetes більше не обов’язково починати з переписування всіх робочих навантажень. У Kubernetes 1.37 підтримка традиційних extended resources у Dynamic Resource Allocation отримала стабільний статус. Про зміни автори проєкту розповіли 3 вересня: DRA поступово перетворюється з окремого способу запитувати обладнання на спільний механізм керування ним.

Що це змінює для команд з AI-інфраструктурою

Уявімо кластер, де десятки сервісів уже запитують прискорювачі через звичне поле ресурсу на кшталт example.com/gpu. Раніше впровадження іншого механізму розподілу могло вимагати змін і від адміністраторів, і від власників застосунків. Тепер ім’я extended resource можна задати у DeviceClass, а запит Pod обслуговуватиме DRA-драйвер. Навантаженню для цього сценарію не потрібно самостійно створювати ResourceClaim.

Ключова користь — поступовість міграції. Маніфести наявних застосунків можуть залишитися незмінними, поки оператори переводять внутрішній розподіл пристроїв на DRA. Автор наголошує, що паралельний окремий device plugin для такого обслуговування не потрібен. Однак це не означає автоматичну сумісність будь-якого GPU: підтримку має забезпечити відповідний драйвер і конфігурація кластера.

Несправний прискорювач — не привід зупиняти весь вузол

Ще одна стабільна можливість — taints і tolerations для пристроїв. Драйвер може позначити конкретний пристрій так, щоб на нього не призначали нові Pod. Адміністратор також отримує DeviceTaintRule для застосування таких правил без переналаштування драйверів.

Для експлуатації це важливіше за ще один пункт у списку API. Якщо один прискорювач потребує обслуговування, можна працювати на рівні цього пристрою. Водночас уже запущені Pod можуть бути автоматично виселені, якщо їхній ResourceClaim не містить відповідного допуску. Тому перед змінами потрібен план завершення задач і відновлення навантаження — новий механізм не гарантує безперервності довгого навчання моделі.

Більше видимості, але не все вже стабільне

У статусі ResourceClaim з’являються відомості про окремі пристрої, зокрема назви мережевих інтерфейсів, MAC та IP-адреси. Стандартизоване ім’я атрибута NUMA допомагає порівнювати топологію обладнання від різних драйверів. Для операторів це крок до зрозумілішого зв’язку між запитом ресурсу та тим, що фактично отримав застосунок.

Але весь пакет нововведень не варто сприймати як готовий до однакового використання в production. Спільні ResourceClaims для Workloads і PodGroups мають статус beta та вимкнені за замовчуванням. Групи сумісності пристроїв і новий шлях повторного планування належать до експериментальних можливостей. Наведене авторами приблизне подвоєння пропускної здатності планування стосується ранніх вимірювань цього окремого шляху, а не універсального прискорення кластера.

Практичний висновок: починати варто зі стабільного мосту між extended resources і DRA на невеликій групі вузлів. Перевірте призначення GPU, поведінку задач під час обслуговування пристрою й сумісність драйвера; експериментальні функції оцінюйте окремо.

Редакційна оцінка: головна новина тут не в кількості нових полів, а в нижчій вартості переходу. Команди можуть модернізувати керування дорогим обладнанням без одночасної міграції всіх застосунків. Виграш у завантаженні GPU або швидкості задач усе одно потрібно вимірювати на власному навантаженні.

Першоджерело та ліцензія

Першоджерело: Kubernetes Blog. Автори: Kashish Verma. Текст перекладено й адаптовано редакцією; пояснення та практичні висновки додано. Ліцензія першоджерела: CC BY 4.0.