При плановом выводе узла Kubernetes не удаётся выселить под: как механизм PodDisruptionBudget влияет на это решение?
PodDisruptionBudget (PDB) ограничивает число реплик, которые можно одновременно вывести из строя из-за добровольных действий: например, при drain узла или плановом обслуживании. Если выселение нарушит заданный минимум доступных реплик или превысит допустимое число недоступных реплик, Kubernetes откладывает операцию.
PDB не резервирует ресурсы, не заменяет readiness-пробы и не защищает от аварийного отказа узла. Он регулирует только управляемые добровольные disruptions.
В кластере поды регулярно перемещаются или удаляются из-за обслуживания узлов, обновлений Kubernetes, изменения конфигурации или балансировки ресурсов. Простое удаление всех подходящих подов с одного узла могло временно вывести из строя слишком много реплик распределённого приложения.
PDB появился как декларативный способ сообщить инфраструктуре минимально допустимую доступность приложения во время таких операций. Это отделяет требования приложения к доступности от конкретного сценария обслуживания узлов.
Предположим, у сервиса пять реплик, а для его работы достаточно четырёх доступных экземпляров. Если при drain одновременно удалить две реплики, останется только три, и доступность сервиса может ухудшиться.
Без PDB оркестратор ориентируется главным образом на возможность пересоздать или переместить поды, но не знает, сколько экземпляров приложение способно потерять без нарушения SLA. Неверно заданный PDB создаёт обратный риск: слишком строгая политика блокирует обслуживание узлов, а слишком мягкая не защищает сервис.
PDB задаёт ограничение через minAvailable или maxUnavailable для группы подов, выбранной по меткам. Например, политика может требовать, чтобы всегда оставалось доступно не менее четырёх реплик либо чтобы недоступной была не более чем одна реплика.
При добровольном выселении Kubernetes проверяет, нарушит ли операция этот бюджет. Если доступных реплик уже недостаточно с учётом требуемого ограничения, запрос на eviction отклоняется или откладывается; инструмент обслуживания узлов обычно повторяет попытку позже.
Под «доступным» обычно понимается под, который считается доступным по условиям Kubernetes, включая его готовность и период стабилизации после запуска. Поэтому корректная readiness-проба важна: если она ошибочно показывает готовность неработающего приложения, PDB будет защищать только формальное состояние, а не реальную способность обслуживать запросы.
PDB действует на добровольные disruptions, но не гарантирует сохранение числа реплик при падении узла, отключении зоны, нехватке памяти или другом аварийном событии. В таких случаях поды могут стать недоступными независимо от бюджета.
Слишком строгий PDB, например разрешающий потерю нуля реплик, способен заблокировать drain единственного узла с экземпляром сервиса. Кроме того, PDB не заменяет распределение реплик по узлам и зонам: если все реплики находятся на одном узле, аварийная потеря узла всё равно нарушит доступность.
При проектировании учитывают размер реплики, время запуска новых подов, домены отказа и реальную ёмкость приложения. Для кворумных систем особенно важно согласовать PDB с требованиями к числу живых участников: формально доступный под не всегда означает сохранение работоспособного кворума.
В кластере работал API с шестью репликами, распределёнными по трём узлам. Во время планового обновления один узел не удавалось вывести из эксплуатации: политика требовала сохранить пять доступных реплик, но на соседних узлах не было ресурсов для запуска замещающих подов.
Рассматривались три варианта. Уменьшить требование до четырёх реплик было быстро, но временно снижало отказоустойчивость. Принудительно удалить поды позволяло завершить обслуживание, однако создавало риск одновременной потери нескольких экземпляров. Увеличить кластер и заранее подготовить ресурсы требовало времени, зато сохраняло доступность.
Выбрали третий вариант: добавили ёмкость, проверили распределение по зонам и оставили PDB с допустимой потерей одной реплики. После появления свободных ресурсов drain завершился без нарушения бюджета, а API продолжил обслуживать трафик.
Нет. PDB ограничивает только операции, которые Kubernetes считает добровольными disruption. Он не предотвращает одновременную потерю подов из-за падения узла, сетевого разделения, сбоя зоны или аварийного удаления.
Кроме того, бюджет не создаёт новые ресурсы и не ускоряет запуск подов. Если оставшиеся экземпляры формально доступны, но приложение перегружено, PDB не распознает это без корректно отражённого состояния готовности и внешних метрик.
Добровольное выселение, которое уменьшит доступность ещё сильнее, обычно будет заблокировано. Kubernetes не может восстановить уже потерянные реплики только за счёт PDB; сначала контроллеры должны попытаться создать замещающие поды.
Если замещение невозможно из-за нехватки ресурсов, ограничений размещения или проблем с образом, обслуживание узла может ждать бесконечно. Это сигнал проверить не только PDB, но и планирование, ёмкость кластера и состояние самого приложения.
Проценты преобразуются в целое число реплик с правилами округления, поэтому результат зависит от размера группы. При небольшом количестве подов даже небольшое процентное изменение может фактически означать запрет потери любой реплики или разрешение потери одной.
Поэтому для критичных небольших сервисов полезно явно проверить вычисленное значение и сопоставить его с кворумом, SLA и временем восстановления. Нельзя оценивать безопасность политики только по её процентному выражению без расчёта для текущего числа реплик.