ТЕХНОЛОГИИ

kubectl drain заблокирован PDB: что защищает disruption budget

В этом материале
ГЛАВНОЕ ЗА МИНУТУ

Если kubectl drain получает отказ eviction, проверьте PodDisruptionBudget и число здоровых реплик. PDB ограничивает определённые добровольные нарушения через Eviction API. Он не предотвращает любой отказ и не блокирует все способы удаления Pod.

Если kubectl drain получает отказ eviction, проверьте PodDisruptionBudget и число здоровых реплик. PDB ограничивает определённые добровольные нарушения через Eviction API. Он не предотвращает любой отказ и не блокирует все способы удаления Pod.

Установите, какое действие заблокировано

Сохраните команду drain, ответ API, selector бюджета и состояние выбранных Pod. Убедитесь, что selector действительно относится к нужному workload, а не захватывает соседние реплики. Посмотрите desired replicas, Ready и allowed disruptions. Учитывайте, что одна реплика может уже отсутствовать из-за другого события. Отказ дальнейшего eviction тогда является ожидаемым следствием бюджета, хотя оператор обслуживает только один дополнительный узел и считает действие небольшим.

Официальный источник 1.

Разделите механизмы удаления

kubectl drain использует eviction и уважает PDB. Прямое удаление Pod или Deployment и rolling update контроллера имеют другие правила; PDB не становится универсальным запретом. Недобровольные нарушения тоже уменьшают доступную ёмкость, но бюджет не способен предотвратить сетевую изоляцию или потерю узла. Не обходите отказ прямым delete, пока не выясните, почему бюджет не допускает действие и какие работающие реплики сохраняют обслуживание.

Официальный источник 2.

Разберите три реплики

В учебном Deployment есть три реплики и minAvailable равен двум. При всех здоровых допускается вывод одной. Если одна реплика уже не Ready, следующий eviction может быть отклонён. Значения иллюстрируют работу бюджета, а не гарантируют непрерывность конкретного inference-сервиса. Проверьте, почему нездоровая реплика не восстанавливается: readiness, недостаток ресурсов и зависимость приложения требуют разных исправлений до продолжения обслуживания узла.

СостояниеРешение оператора
Все три ReadyПроверить разрешение одного eviction
Одна не ReadyВосстановить причину потери ёмкости
Selector не тотИсправить область бюджета
Drain ждёт DaemonSetРазобрать отдельное правило drain

Учитывайте нездоровые Pod

Политика unhealthyPodEvictionPolicy влияет на вывод нездоровых экземпляров. Документация рекомендует рассматривать AlwaysAllow для возможности обслуживания проблемных Pod, но выбор должен соответствовать приложению и версии кластера. Не меняйте minAvailable только ради завершения команды без оценки остающейся ёмкости. DaemonSet обрабатываются отдельно: —ignore-daemonsets не означает, что их процессы остановлены и узел больше ничем не занят. Сохраните этот факт в плане обслуживания.

Завершите процедуру проверкой

После допустимого drain подтвердите размещение и готовность оставшихся реплик, затем выполните предусмотренное обслуживание и uncordon, если узел возвращается. Артефакт содержит selector, состояние Ready до действия, ответ eviction и состояние после него. Успешное завершение команды показывает выполненный набор допустимых eviction, но не заменяет прикладную проверку. Для следующего окна сохраняйте тот же протокол, чтобы отличать ожидаемую блокировку бюджета от новой проблемы приложения или планирования.

Перед параллельным обслуживанием нескольких узлов сопоставьте совокупную потребность в eviction. Отдельные команды drain должны наблюдаться как части общего изменения ёмкости, а не как независимые безопасные действия по числу терминалов оператора.

Связанные разборы: gpu exit plan; gpu maintenance change register.

← Все материалы