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

Диагностика: kubectl drain заблокирован PDB: что защищает disruption budget. Признаки, последовательность проверки, рабочий пример и критерии восстановления.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/kubernetes-pdb-voluntary-disruption/
Language: ru

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

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

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


[Официальный источник 1](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/).

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

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


[Официальный источник 2](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/).

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

В учебном 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](/ru/journal/gpu-exit-plan/); [gpu maintenance change register](/ru/journal/gpu-maintenance-change-register/).