В этом материале
Rolling update GPU Deployment может остановиться на Pending, если новой реплике требуется свободный GPU, а все устройства уже заняты старыми Pod. Проверьте maxSurge и maxUnavailable: разрешение создать Pod не означает наличие ресурса для его запуска.
Rolling update GPU Deployment может остановиться на Pending, если новой реплике требуется свободный GPU, а все устройства уже заняты старыми Pod. Проверьте maxSurge и maxUnavailable: разрешение создать Pod не означает наличие ресурса для его запуска.
Сначала подтвердите стадию ожидания
Сохраните Deployment conditions, ReplicaSet и события Pending Pod. Отличите FailedScheduling от загрузки образа и неуспешной readiness. Посмотрите запросы ресурсов нового и старого шаблона, ограничения узлов и реально доступную ёмкость. Свободный GPU на другом узле может не соответствовать affinity или требуемой памяти хоста. Основная проблема этой процедуры — обновление при исчерпанной ёмкости, а не первоначальная установка GPU device plugin или объявление количества устройств.
Посчитайте допустимое перекрытие
maxSurge задаёт, сколько дополнительных Pod можно создать, maxUnavailable — сколько желаемых реплик разрешено временно потерять. Проценты округляются по разным правилам. При одной реплике особенно важно вычислить фактические целые значения. Завершающиеся Pod могут продолжать расходовать ресурсы, поэтому число объектов само по себе не доказывает освобождение устройства. Progress deadline сообщает проблему прогресса, но не создаёт новый GPU и не исправляет выбранную стратегию автоматически.
Разберите один занятый ускоритель
В учебном кластере одна реплика занимает единственный подходящий GPU. Стратегия maxSurge 1 и maxUnavailable 0 создаёт вторую реплику, которой негде работать, сохраняя первую. Это ожидаемое ограничение ёмкости. Вариант без дополнительного GPU требует допустить временную недоступность или иной явно спроектированный переход. Пример не обещает, что смена этих чисел даст обновление без перерыва или что устройство мгновенно освободится после удаления Pod.
| Вариант | Следствие для плана |
|---|---|
| Есть запасной GPU | Можно проверить перекрытие реплик |
| Запаса нет | Нужна допустимая последовательная замена |
| Старый Pod завершается | Следует дождаться освобождения ресурсов |
| Новый Pod Pending | Читать конкретную причину планирования |
Выберите осознанную стратегию
Согласуйте допустимый перерыв, время подготовки нового образа и способ возврата. Если требуется overlap, предварительно обеспечьте подходящую ёмкость. Если допускается последовательная замена, рассчитайте параметры rollout и подтвердите их на тестовом workload. PDB не является универсальным ограничителем rolling update Deployment: эти механизмы имеют разные области действия. Не исправляйте стратегию удалением случайных соседних Pod, чтобы освободить устройство без понимания их владельца и обязательств.
Проверьте обновление и откат
Сохраните timeline: создание ReplicaSet, Pending, завершение старого процесса, назначение GPU и готовность новой реплики. Затем проверьте возврат на предыдущий digest с той же политикой ёмкости. Успех означает предсказуемое прохождение перехода при выбранном допустимом перерыве. Артефакт должен содержать целые значения surge/unavailable и наблюдаемые причины ожидания. Такой протокол помогает отличить ошибку стратегии от отказа образа, не скрывая стоимость дополнительной ёмкости за успешным статусом контроллера.
Для сравнения сохраните время освобождения устройства отдельно от удаления объекта API. Эти отметки позволяют увидеть, где заканчивается controller transition и начинается ожидание фактического завершения старой рабочей среды.
Связанные разборы: kubernetes gpu scheduling; model update canary.