Отказ GPU в Kubernetes: как выйти из Pending без перезапуска ноды

Когда видеокарта в Kubernetes-кластере выходит из строя, стандартный подход «перезапусти контейнер» не работает: kubelet поднимет под на том же мёртвом устройстве, и всё повторится. В этой статье мы разберём, что происходит с подом после отказа GPU, как это выглядит в kubectl и какие механизмы появи

Проблема: GPU отказывают, а Kubernetes не замечает

Kubernetes изначально проектировался для stateless-сервисов, где рестарт решает большинство проблем. Но с GPU всё иначе. Если контейнер упал из-за сбоя видеокарты, kubelet перезапустит его на том же устройстве, и ошибка повторится. В итоге под зависает в состоянии Pending или CrashLoopBackOff, а оператор вручную удаляет под или перезагружает ноду. Это не только неудобно, но и дорого: каждая минута простоя GPU-кластера — это потерянные деньги и время.

По данным статьи 2024 года, кластер Meta из 16 384 карт H100 за 54 дня обучения Llama 3 405B пережил 419 внезапных прерываний, 58,7% из которых пришлись на GPU и их память. Процессоры за это время отказали всего дважды. Опрос CNCF за 2025 год показал, что 82% пользователей контейнеров используют Kubernetes в проде, а 66% компаний с genAI-моделями держат на нём инференс. Так что проблема массовая.

Как выглядит отказ GPU в Kubernetes

Чтобы понять механику, автор статьи Стас Погоржельский из VK Cloud собрал отказный стенд. Он использовал кластер с GPU-нодами, где одна из видеокарт была программно «убита» для имитации сбоя. После отказа пода с GPU kubelet попытался перезапустить контейнер, но устройство осталось недоступным. В kubectl под перешёл в состояние Pending с сообщением о невозможности выделить ресурс.

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

Предыстория и контекст: как развивалась поддержка GPU

Долгое время Kubernetes не имел нативной поддержки GPU. Устройства выделялись через device plugin, который просто сообщал о наличии ресурсов. Если GPU умирал, kubelet узнавал об этом только после того, как контейнер начинал падать. В 2023 году появилась технология DRA (Dynamic Resource Allocation), которая позволила более гибко управлять ресурсами, но она не решала проблему отказа устройств.

Параллельно с этим росло количество AI-нагрузок в Kubernetes. По данным CNCF, за последние два года число компаний, использующих Kubernetes для инференса, выросло в разы. Это подтолкнуло сообщество к разработке механизмов, которые могли бы автоматически обрабатывать отказы GPU.

Что изменилось в Kubernetes 1.36?

Версия Kubernetes 1.36, вышедшая в середине 2025 года, представила два ключевых механизма: Device Health Status и Device Taint. Первый позволяет device plugin сообщать о состоянии конкретного устройства, второй — помечать ноду как непригодную для выделения сломанных GPU. Благодаря этому планировщик может избегать назначения подов на устройства, которые числятся в списке нездоровых.

Как работают новые механизмы

Device Health Status — это расширение API device plugin. Теперь плагин может отправлять в kubelet информацию о состоянии каждого устройства: healthy, unhealthy, unknown. Если устройство помечено как unhealthy, kubelet не будет пытаться выделить его новым подам. Более того, если под уже использует такое устройство, kubelet может инициировать его перезапуск на другой ноде.

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

Кого затронет и как

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

Для компаний, использующих Kubernetes для инференса AI-моделей, это означает более стабильную работу сервисов. Особенно это актуально для российских компаний, где GPU-кластеры часто строятся на базе VK Cloud или аналогичных платформ.

Что будет дальше

Механизмы Device Health Status и Device Taint уже доступны в Kubernetes 1.36, но они пока не включены по умолчанию. Ожидается, что в следующих версиях они станут стандартом, а device plugin для NVIDIA и AMD добавят поддержку автоматического обнаружения сбоев. Также вероятно развитие DRA в сторону более тесной интеграции с этими механизмами.

Итог

Отказ GPU — это не баг, а реальность, с которой сталкиваются все, кто запускает AI-нагрузки в Kubernetes. Новые механизмы в версии 1.36 позволяют автоматически обрабатывать сбои устройств и избегать вечного Pending. Если вы используете GPU в проде, стоит обратить внимание на эти возможности и протестировать их на своих кластерах. Это может сэкономить вам часы ручной работы и нервы.