Запрет размещения приняли за эвакуацию. Разбираем сценарий планового вывода: оператор выставил Longhorn-узлу spec.allowScheduling=false и выключил сервер. Приложения получили задержки или ошибки I/O, тома потеряли реплики. При потере последней исправной реплики том стал недоступен. Ложный диагноз — «сломался диск». Причина — флаг запрещает новое размещение, но не переносит существующие данные. Первый срез: kubectl -n longhorn-system get nodes.longhorn.io NODE -o yaml. Проверяем spec.allowScheduling и spec.evictionRequested. Затем kubectl -n longhorn-system get replicas.longhorn.io -o wide — выясняем, какие реплики остались на узле. На хосте cat /proc/pressure/io покажет долю времени задержек из-за I/O, iostat -xz 1 — await и очередь устройств. Это признаки ожидания, а не доказательство неисправности NVMe: намерения оператора ядро не читает. Для эвакуации: kubectl -n longhorn-system patch nodes.longhorn.io NODE --type=merge -p '{"spec":{"allowScheduling":false,"evictionRequested":true}}'. Запрос принят — работа ещё не закончена. До отключения проверяем, что реплики вывезены, затронутые тома healthy и нужное число исправных реплик размещено вне выводимого узла. Без свободного места и допустимых узлов назначения эвакуация не завершится. Перенос workloads и отключение томов тоже входят в обслуживание: один storage-флаг их не выполняет. Kubernetes умеет принять декларацию быстрее, чем storage успевает скопировать данные. Принимать успешный patch за разрешение выдернуть питание — дорогая форма оптимизма. Критерий завершения обслуживания задаётся состоянием данных, а не кодом возврата API. https://ftops.space/?utm*source=telegram&utm*medium=smm&utm*campaign=ftops&utm*content=izolyatsiya-longhorn-storage-allowsche
