Запретить Longhorn размещать новые реплики и выдернуть сервер — два действия, между которыми забыли эвакуацию данных. Сценарий плановых работ: выставили spec.allowScheduling=false, выключили узел, получили degraded volumes и алерты приложения на задержки I/O. Поверхностный диагноз — «сеть между узлами». Фактический промах: запрет планирования приняли за перенос существующих реплик. Сам по себе этот флаг их не переносит. Начинаем с kubectl -n longhorn-system get nodes.longhorn.io NODE -o yaml и kubectl -n longhorn-system get replicas.longhorn.io -o wide. Проверяем размещение реплик и состояние томов: kubectl -n longhorn-system get volumes.longhorn.io. На оставшихся хостах смотрим iostat -xz 1 и cat /proc/pressure/io: await, очередь диска и PSI показывают давление на I/O, в том числе при восстановлении реплик. Это последствия нагрузки, а не доказательство сетевой аварии. Рост retrans в nstat -az тоже требует проверки по времени, а не гадания по накопленному счётчику. Для эвакуации storage нужны запрет нового размещения и запрос выселения: spec.allowScheduling=false вместе со spec.evictionRequested=true на Longhorn Node. Запрос не равен завершению: нужны доступные узлы, место и выполнение ограничений размещения. Перед отключением проверяем, что на выводимом узле не осталось реплик, а затронутые тома восстановили требуемую избыточность на остальных узлах. Kubernetes cordon и drain не заменяют эту проверку; для workload отдельно учитываем политику drain Longhorn. K8s охотно принимает декларацию намерений. За физическое размещение данных всё равно отвечает инженер. Если в регламенте после PATCH сразу идёт poweroff, автоматизирована потеря запаса отказоустойчивости. Критерий завершения работ — состояние данных, подтверждённое проверкой: https://ftops.space/?utm*source=telegram&utm*medium=smm&utm*campaign=ftops&utm*content=izolyatsiya-longhorn-storage-allowsche.
