Как решить проблему Pending при отказе GPU в Kubernetes: Device Health Detection

Когда в кластере Kubernetes выходит из строя видеокарта, под с GPU часто навсегда застревает в статусе Pending. Это происходит потому, что стандартные механизмы не отличают отказ оборудования от ошибки приложения. Однако с выходом Kubernetes 1.36 появилось решение — Device Health Detection, которое автоматически переносит поды на здоровые устройства. В этой статье разберем, как это работает и что нужно сделать, чтобы навсегда избавиться от ручного вмешательства.

Представьте: вы обучаете большую языковую модель на кластере Kubernetes, и вдруг одна из видеокарт умирает. Если вы работали с GPU в кубере, то знаете, что дальше начинается ад. Под с GPU не перезапускается на другом устройстве — он застревает в статусе Pending, и единственный способ выйти из ситуации — вручную убить под или перезагрузить ноду. Но в 2024 году Meta опубликовала данные, которые показывают, насколько это частая проблема: за 54 дня обучения Llama 3 405B на кластере из 16 384 карт H100 произошло 419 внезапных прерываний — примерно одно каждые три часа. При этом 58,7% всех отказов пришлись именно на GPU и их память. Процессоры за то же время отказали всего дважды.

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

Почему под с GPU застревает в Pending при отказе устройства

Когда GPU выходит из строя, kubelet обнаруживает проблему при следующей попытке запуска контейнера. Он пытается перезапустить под на той же ноде, но устройство уже не работает. В результате под переходит в состояние Pending и остается там навсегда, потому что кластер не знает, что GPU сломан.

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

В реальных условиях, когда на кластере работают тысячи подов, ручное вмешательство становится не просто неудобным, а критическим. Каждый час простоя — это потерянные деньги и время. Особенно остро это ощущается в индустрии, где 82% пользователей контейнеров уже используют Kubernetes в продакшене, а 66% компаний с genAI-моделями держат на нем инференс, как показал опрос CNCF за 2025 год.

Как Kubernetes развивался в сторону GPU: от extended resources до DRA

Долгое время GPU в Kubernetes были экзотикой. Первые эксперименты начались еще в 2017 году, когда NVIDIA представила свой плагин устройства. Тогда считалось, что GPU — это просто еще один ресурс, который можно выделять и освобождать, как CPU или память. Но GPU — это не CPU. Это сложное устройство, которое может выйти из строя, перегреться или потерять связь с драйвером, и это не зависит от того, что происходит в контейнере.

В 2022 году появилась инициатива Dynamic Resource Allocation (DRA), которая должна была заменить устаревший Extended Resource Model. DRA позволяет управлять ресурсами более гибко: выделять GPU с учетом их состояния, поддерживать разные модели разделения и даже учитывать топологию устройства. Но до недавнего времени DRA не решала проблему отказа устройства — она лишь улучшала способ выделения ресурсов.

И вот в Kubernetes 1.36 появился механизм, который закрывает этот пробел. Он называется Device Health Detection и работает в связке с DRA. Суть в том, что kubelet теперь может отслеживать состояние устройств в реальном времени и сообщать планировщику, что конкретный GPU больше не доступен. Это позволяет автоматически переносить под на другое устройство — без вечного Pending.

Что такое Device Health Detection в Kubernetes 1.36 и как он работает

Device Health Detection — это не одна фича, а комплекс изменений. Во-первых, kubelet теперь умеет получать от драйвера устройства информацию о его здоровье. Если драйвер сообщает, что устройство сломано, kubelet помечает его как unhealthy и больше не пытается запускать на нем поды.

Во-вторых, планировщик получает эту информацию через обновленный API. Когда под с GPU запрашивает устройство, планировщик видит только здоровые устройства. Если под уже запущен на ноде, где устройство умерло, планировщик может пересоздать его на другой ноде.

В-третьих, для подов, которые уже работают, вводится механизм перезапуска с учетом здоровья устройства. Если kubelet обнаруживает, что GPU, на котором работает контейнер, сломан, он инициирует перезапуск пода на другой ноде. Это похоже на то, как Kubernetes обрабатывает отказ обычного пода, но с учетом специфики GPU.

Однако важно понимать: Device Health Detection работает только с DRA. Если вы используете старый способ выделения GPU через extended resources, вам придется перейти на DRA, чтобы воспользоваться новыми возможностями. Это потребует изменений в конфигурации кластера, но результат того стоит.

Как происходит автоматический перенос пода при отказе GPU?

Давайте разберем, что происходит при отказе GPU в кластере с Kubernetes 1.36 и DRA. Предположим, у вас есть нода с четырьмя GPU, и один из них умирает. Kubelet, работающий на этой ноде, получает сигнал от драйвера о том, что устройство нездорово. Он обновляет статус устройства в API Kubernetes, помечая его как unhealthy.

Планировщик, который постоянно следит за состоянием кластера, узнает об этом и перестает назначать поды на эту ноду. Если на ноде уже работает под с GPU, который требует именно этот умерший GPU, планировщик инициирует его пересоздание на другой ноде, где есть здоровые GPU.

Ключевой момент: под не просто перезапускается на той же ноде — он переносится на другую. Это возможно благодаря тому, что DRA хранит информацию о том, какое устройство выделено поду, и эта информация обновляется при изменении состояния устройства.

Для администратора это означает, что больше не нужно вручную удалять поды или перезагружать ноды. Кластер сам справляется с отказами GPU. Но есть нюанс: если все GPU на всех нодах вышли из строя, под все равно останется в Pending — просто потому, что нет доступных устройств. В этом случае механизм не поможет, но это уже вопрос емкости кластера.

Кому и как поможет Device Health Detection

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

Разработчикам, которые пишут операторы для GPU-ресурсов, стоит обратить внимание на изменения в API. Новые поля и события позволят создавать более умные операторы, которые могут реагировать на отказы устройств без участия человека.

Для компаний, которые используют облачные Kubernetes-платформы, это означает повышение надежности. VK Cloud, например, уже предоставляет GPU-кластеры на базе Kubernetes, и внедрение Device Health Detection позволит уменьшить время простоя для клиентов.

Особенно это важно для СНГ-рынка, где растет число AI-стартапов и корпоративных проектов, использующих GPU. Раньше отказ GPU мог остановить обучение модели на несколько часов, пока администратор не разберется с проблемой. Теперь этот процесс станет автоматическим.

Что дальше: будущее управления GPU в Kubernetes

Device Health Detection — это только первый шаг. В следующих версиях Kubernetes ожидается дальнейшее развитие DRA, включая более тонкое управление ресурсами и поддержку новых типов устройств. Например, уже обсуждается возможность горячей замены GPU без остановки пода — это станет возможным благодаря улучшению механизмов обнаружения и миграции.

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

Если вы хотите быть на передовой, рекомендую начать тестировать DRA в своих кластерах уже сегодня. Переход может потребовать времени, но он окупится, когда ваш кластер столкнется с первым отказом GPU.

Итог

Отказ GPU в Kubernetes — это не приговор. С выходом Kubernetes 1.36 и механизма Device Health Detection у вас есть возможность автоматически обрабатывать сбои устройств, не застревая в вечном Pending. Внедрение DRA и нового механизма требует усилий, но они окупаются многократно: меньше ручного труда, выше надежность, быстрее обучение моделей. Начните с тестирования на небольшом кластере, и вы убедитесь, что эта проблема решаема.