# Узел NotReady, а Pod не переносится: tolerationSeconds и eviction

Диагностика: Узел NotReady, а Pod не переносится: tolerationSeconds и eviction. Признаки, последовательность проверки, рабочий пример и критерии восстановления.

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

Недоступный узел не означает мгновенный перенос всех Pod. Kubernetes сначала обнаруживает проблему, обновляет состояние и taints, затем учитывает tolerationSeconds и правила eviction. Проверьте фактическую цепочку событий, прежде чем считать медленное восстановление ошибкой scheduler.

## Сохраните состояние обеих сторон

Запишите Node Ready, последние переходы conditions, taints и состояние Pod с UID. Если узел недоступен control plane, приложение на нём может продолжать работать: отсутствие связи не подтверждает остановку процесса. При сетевой изоляции это особенно важно для задач с внешними побочными эффектами. Не создавайте вручную дубликат только потому, что dashboard не видит heartbeat. Сначала установите, какие гарантии остановки и повторного выполнения предусмотрены выбранным workload.


[Официальный источник 1](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/).

## Проверьте tolerations

Для not-ready и unreachable Kubernetes обычно добавляет NoExecute tolerations с tolerationSeconds 300, если они явно не заданы иначе. Это означает ожидание после обнаружения соответствующей проблемы, а не обещанное время восстановления от физического сбоя. У DaemonSet другая политика tolerations. Дополнительно учитываются конфигурация controller, ограничения скорости eviction и состояние зоны. Сверяйте документацию с установленной версией: архитектура taint eviction controller менялась, а время обнаружения добавляется к сроку ожидания.


[Официальный источник 2](https://kubernetes.io/docs/concepts/architecture/nodes/).

## Разберите сетевой разрыв

В учебном сценарии узел теряет связь с control plane, Ready становится Unknown, Pod остаётся привязанным до окончания допустимого ожидания. На другом узле может оказаться недостаточно подходящей GPU-ёмкости даже после eviction. Поэтому длинный интервал складывается из обнаружения, toleration, удаления, планирования и подготовки новой реплики. Уменьшение одного числа не сокращает автоматически все остальные стадии и не доказывает, что старый процесс больше не выполняется.

| Этап | Нужное подтверждение |
| --- | --- |
| Обнаружение | Переход Node condition |
| Ожидание | NoExecute taint и toleration |
| Выселение | Событие controller и состояние Pod |
| Замена | Новый UID, scheduling и readiness |


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

## Меняйте policy с учётом изоляции

Короткое ожидание может ускорить создание замены, но повышает вероятность лишнего перемещения при кратком разрыве. Длинное сохраняет привязку к узлу, но откладывает реакцию на реальную потерю. Для stateful операций нужны дополнительные механизмы владения и защиты от одновременной работы. Force delete удаляет объект API без подтверждения остановки процесса, поэтому не используйте его как доказательство освобождения ресурса. Решение должно описывать допустимый сценарий разделения сети, а не только желаемую цифру задержки.

## Измерьте полную временную шкалу

В тестовой среде отдельно воспроизведите короткий разрыв и длительную недоступность, соблюдая границы допустимого воздействия. Сохраните conditions, tolerations, события eviction и время реальной готовности замены. После возврата узла проверьте старые процессы и назначение ресурсов. Итоговый артефакт показывает, где потрачено время и какие утверждения подтверждены. Он помогает отличить ожидаемую политику ожидания от нехватки GPU, неготовности приложения или несогласованного состояния после сетевой изоляции.

Связанные разборы: [network and uptime](/ru/journal/network-and-uptime/); [gpu owner network outage log](/ru/journal/gpu-owner-network-outage-log/).