В этом материале
Недоступный узел не означает мгновенный перенос всех Pod. Kubernetes сначала обнаруживает проблему, обновляет состояние и taints, затем учитывает tolerationSeconds и правила eviction. Проверьте фактическую цепочку событий, прежде чем считать медленное восстановление ошибкой scheduler.
Недоступный узел не означает мгновенный перенос всех Pod. Kubernetes сначала обнаруживает проблему, обновляет состояние и taints, затем учитывает tolerationSeconds и правила eviction. Проверьте фактическую цепочку событий, прежде чем считать медленное восстановление ошибкой scheduler.
Сохраните состояние обеих сторон
Запишите Node Ready, последние переходы conditions, taints и состояние Pod с UID. Если узел недоступен control plane, приложение на нём может продолжать работать: отсутствие связи не подтверждает остановку процесса. При сетевой изоляции это особенно важно для задач с внешними побочными эффектами. Не создавайте вручную дубликат только потому, что dashboard не видит heartbeat. Сначала установите, какие гарантии остановки и повторного выполнения предусмотрены выбранным workload.
Проверьте tolerations
Для not-ready и unreachable Kubernetes обычно добавляет NoExecute tolerations с tolerationSeconds 300, если они явно не заданы иначе. Это означает ожидание после обнаружения соответствующей проблемы, а не обещанное время восстановления от физического сбоя. У DaemonSet другая политика tolerations. Дополнительно учитываются конфигурация controller, ограничения скорости eviction и состояние зоны. Сверяйте документацию с установленной версией: архитектура taint eviction controller менялась, а время обнаружения добавляется к сроку ожидания.
Разберите сетевой разрыв
В учебном сценарии узел теряет связь с control plane, Ready становится Unknown, Pod остаётся привязанным до окончания допустимого ожидания. На другом узле может оказаться недостаточно подходящей GPU-ёмкости даже после eviction. Поэтому длинный интервал складывается из обнаружения, toleration, удаления, планирования и подготовки новой реплики. Уменьшение одного числа не сокращает автоматически все остальные стадии и не доказывает, что старый процесс больше не выполняется.
| Этап | Нужное подтверждение |
|---|---|
| Обнаружение | Переход Node condition |
| Ожидание | NoExecute taint и toleration |
| Выселение | Событие controller и состояние Pod |
| Замена | Новый UID, scheduling и readiness |
Меняйте policy с учётом изоляции
Короткое ожидание может ускорить создание замены, но повышает вероятность лишнего перемещения при кратком разрыве. Длинное сохраняет привязку к узлу, но откладывает реакцию на реальную потерю. Для stateful операций нужны дополнительные механизмы владения и защиты от одновременной работы. Force delete удаляет объект API без подтверждения остановки процесса, поэтому не используйте его как доказательство освобождения ресурса. Решение должно описывать допустимый сценарий разделения сети, а не только желаемую цифру задержки.
Измерьте полную временную шкалу
В тестовой среде отдельно воспроизведите короткий разрыв и длительную недоступность, соблюдая границы допустимого воздействия. Сохраните conditions, tolerations, события eviction и время реальной готовности замены. После возврата узла проверьте старые процессы и назначение ресурсов. Итоговый артефакт показывает, где потрачено время и какие утверждения подтверждены. Он помогает отличить ожидаемую политику ожидания от нехватки GPU, неготовности приложения или несогласованного состояния после сетевой изоляции.
Связанные разборы: network and uptime; gpu owner network outage log.