Управління збоєм пристроїв у подах Kubernetes

Kubernetes став основою сучасної оркестрації контейнерів, але з ростом навантажень AI/ML та зростаючою популярністю спеціалізованих прискорювачів, таких як GPU, FPGA та ASIC, модель відмов платформи опинилася під тиском. Виходячи з доповіді Сергія Канжелева та Мрунала Пателя на KubeCon NA 2024 та останніх розробок Kubernetes 1.30, ця стаття розглядає моделі відмов, найкращі практики та дорожню карту до надійного управління пристроями.

Бум AI/ML та його вплив на Kubernetes

Зростання навантажень AI/ML привнесло до кластерів Kubernetes завдання, які мають тісну прив’язку, чутливі до затримок і вимагають великих ресурсів. Згідно з документом 2024 року Llama 3, апаратні збої, зокрема помилки ECC GPU і збої VRAM, є основною причиною перерв у навчанні. В інфраструктурі GeForce NOW від NVIDIA, яка відновлюється автоматично (19 запитів на усунення неполадок на 1000 вузлів на день), відмови вузлів та живе міграція віртуальних машин підкреслюють операційне навантаження з управління флотами GPU.

Пропозиції спотових інстансів та перевантаження потужності в публічних хмарах нормалізували непостійність доступності пристроїв. Проте статична модель ресурсів Kubernetes все ще розглядає пристрої як бінарні: або повністю присутні, або відсутні. Немає рідної концепції часткових відмов (наприклад, зниження продуктивності PCIe, помилки, виправлені ECC) або тимчасових збоїв, що призводить до сліпих зон у плануванні, розподілі та управлінні життєвим циклом.

Розуміння навантажень AI/ML

Завдання AI/ML зазвичай вимагають специфічних типів пристроїв (наприклад, NVIDIA A100 з MIG-партіями або AMD MI250x), що ставить під сумнів припущення Kubernetes. Загалом, навантаження поділяються на:

Навчання

Групові завдання, які виконуються до завершення і можуть тривати дні або тижні. Відмова одного пода може вимагати повного відкату, якщо не реалізовані складні механізми контрольних точок та оркестрації (наприклад, MPI/Horovod).

Висновок

Довготривалі сервіси або пакетні кінцеві точки, які можуть потребувати гарячих замін моделей, багатоядерного висновку або завантаження великих ваг (більше 10 ГБ) через сайдкари або контейнери ініціалізації.

Спадкові припущення проти сучасних вимог

Традиційні проекти Kubernetes виходили з таких припущень:

Чому Kubernetes все ще залишається на вершині

Незважаючи на ці виклики, Kubernetes залишається стандартом для AI/ML завдяки своєму багатому екосистемному середовищу (Kubeflow, KEDA, Volcano), всебічній моделі безпеки (RBAC, SELinux, seccomp) та широкій підтримці спільноти. Постійні зусилля, такі як API управління ресурсами пристроїв (DRA) в KEP-5030 та динамічне управління здоров’ям пристроїв в альфа-версії Kubernetes 1.30, свідчать про еволюцію платформи в напрямку кращого управління відмовами пристроїв.

Сучасний стан управління відмовами пристроїв

Моделі відмов: інфраструктура K8s

Планування пода з пристроями включає кількох учасників:

1. Плагін пристрою стартує на вузлі.
2. Плагін пристрою реєструється через gRPC в kubelet.
3. Kubelet повідомляє про оновлення потужності на API-сервер.
4. Планувальник прив’язує под до вузла.
5. Kubelet викликає Allocate на плагіні пристрою.
6. Kubelet запускає контейнер з монтуваннями пристроїв хоста та модулями драйверів.

Кожен з цих кроків може зазнати невдачі: збої плагіна, зависання gRPC, перезапуск kubelet або помилки прив’язки пристроїв CRI-O. Дорожня карта SIG Node включає:

• Інтеграцію системного монітора для kubelet (#127460).
• Перевірки стану сокетів плагіна DRA (#128696).
• Перехоплення управління пристроями та надійність (#127803).
• Гладкі повторні спроби на невдачах gRPC плагіна (#128043).

Найкращі практики:

• Моніторинг метрик плагіна (затримка gRPC, Allocatable проти Capacity).
• Ізоляція критичних вузлів GPU; уникнення спільного розташування навантажень розробки/тестування.
• Використання канарейкових оновлень для драйверів через DaemonSets.
• Використання tolerations та gracefulTermination для нестабільності вузлів.

Моделі відмов: відмова пристрою

На даний момент, коли GPU зазнає апаратних помилок або зависання прошивки, плагіни пристроїв просто відкликають потужність. Kubernetes не пов’язує помилки ECC GPU з перезапусками контейнерів. Поширені самостійні шаблони:

Контролер здоров’я

Користувацький контролер відстежує метрики allocatable проти capacity. При перевищенні порогу він обмежує та зливає вузол. Недоліки: відсутність контексту навантаження, грубе виявлення та можливе порушення роботи здорових подів.

Політика відмови подів

Завдання виводять спеціальні коди виходу для несправностей пристроїв. Політика відмови подів Kubernetes може обробляти їх як такі, що не підлягають повторному виконанню. Обмеження включають відсутність загального статусу deviceFailed та сумісність лише з restartPolicy: Never.

Користувацький спостерігач подів

Агенти на локальному вузлі опитують NVIDIA DCGM, AMD ROCm SMI або RDMA ibdiagnet для виявлення зниження продуктивності або зависань. Вони зв’язують несправні пристрої з подами через API ресурсів подів і видаляють поди для ініціювання повторного планування. Це вимагає підвищених привілеїв та зовнішніх контролерів для відновлення запланованої кількості.

Моделі відмов: невдача коду контейнера

Kubernetes обробляє OOM вбивства та ненульові виходи однаково: перезапуск або відмова. Навчання AI/ML виграє від оркестраторів (наприклад, оператор MPI, Volcano), які координують групові перезапуски та перезапуски контейнерів на місці, щоб зберегти прив’язки пристроїв, зменшуючи холодні старт.

Моделі відмов: деградація пристрою

Часткова втрата продуктивності, як-от зниження пропускної здатності FP16 через глюки обмеження потужності, не може бути висловлена. Виявлення залежить від телеметрії завдань: сплески затримок кроків або помилки перерахунку BDF (Bus/Device/Function). Не існує рідної виправлення, окрім переробки вузлів або ручного перезавантаження драйверів.

Кейс: Реальні відключення та отримані уроки

На початку 2024 року один з великих постачальників хмарних послуг зазнав 30-хвилинного відключення у своєму флоті A100 через регресію прошивки. Автоматизовані сценарії виправлення викликали повні перезавантаження вузлів, але без правил афіліації подів деякі навчальні роботи втратили контрольні точки. Інцидент підкреслив:

• Необхідність анотацій здоров’я пристроїв на рівні подів.
• Важливість координації контрольних точок між подами.
• Цінність канарейкових розгортань прошивки з поетапними випусками.

Нові стандарти та сторонні інструменти

Окрім вбудованого Kubernetes, проекти, такі як node-healthcheck-operator та Volcano, пропонують багатші API здоров’я. Галузеві групи обговорюють стандарти Device Health API під егідою CNCF для уніфікації сигналів між постачальниками — узгоджуючи метрики, такі як кількість виправлених ECC проти невиправних, скидання PCI та події термічного обмеження.

Безпекові наслідки управління пристроями

Відкриття API здоров’я пристроїв та їх розподілу збільшує поверхню атаки. Найкращі практики включають:

• Правила RBAC, які обмежують доступ до PodResources та NodeMetrics.
• Запуск плагінів пристроїв з мінімальними можливостями (без root).
• Увімкнення профілів seccomp під час установки DaemonSets драйверів.

Дорожня карта

SIG Node надає пріоритет точкам розширення над спеціалізованими семантиками для адаптації до різноманітних навантажень. Ключові ініціативи:

Покращення інфраструктури K8s

• Інтеграція системного монітора та логіки повторного підключення gRPC.
• Детектори стану сокетів плагіна (#128696).
• Перехоплення DRA та метадані здоров’я ResourceSlice.

Обробка відмов пристроїв

• Реалізація KEP-4680: Статус здоров’я ресурсів у PodStatus.
• Інтеграція подій пристроїв у Політику відмови подів.
• Підтримка семантики deschedule для подів, які завжди перезапускаються.

Відновлення при невдачі коду контейнера

• Перезапуски контейнерів на місці з збереженими монтуваннями пристроїв хоста.
• Стан знімків та відновлення стану контейнера.
• Локальні політики перезапуску вузлів, щоб уникнути повного повторного планування.

Видимість деградації пристрою

• Розширення ResourceSlice для включення лічильників продуктивності.
• Визначення стандартного статусу degraded в API DRA.
• Співпраця з постачальниками щодо експортерів телеметрії (метрики Prometheus).

Приєднуйтесь до обговорення

Ваші відгуки є важливими. Беріть участь у зустрічах SIG Node або вносьте свій внесок у KEP на GitHub. Разом ми можемо створити більш стійкий Kubernetes для наступної ери AI/ML.