В этом материале
Зависший Terminating ресурс с finalizer обычно ждёт завершения предусмотренной очистки. Сначала найдите контроллер и зависимые объекты. Ручное удаление ключа finalizer может убрать объект API, оставив реальные ресурсы и нарушенные зависимости, поэтому это не универсальное исправление.
Зависший Terminating ресурс с finalizer обычно ждёт завершения предусмотренной очистки. Сначала найдите контроллер и зависимые объекты. Ручное удаление ключа finalizer может убрать объект API, оставив реальные ресурсы и нарушенные зависимости, поэтому это не универсальное исправление.
Сохраните метаданные удаления
Получите deletionTimestamp, finalizers, ownerReferences, UID и события объекта. Сравните состояние владельца и потомков. Finalizer — это ключ, на который реагирует контроллер, а не текст исполняемой команды внутри объекта. Выясните, какой компонент должен выполнить cleanup и убрать ключ. Состояние Terminating может сохраняться при недоступном контроллере, отказе внешней зависимости или действительно незавершённом использовании ресурса. Разные причины требуют разных действий и разных подтверждений выполненной очистки.
Проследите зависимость до владельца
При foreground и background deletion порядок удаления связанных объектов различается. Owner reference помогает понять каскад, но не заменяет назначение конкретного finalizer. Для volume protection ожидаемое поведение может состоять в сохранении объекта, пока его использует Pod. Удаление finalizer в таком случае скрывает защиту, а не восстанавливает controller. Проверьте также namespace и идентификаторы: новый объект с прежним именем не обязательно является владельцем старой зависимости из-за другого UID.
Разберите отказ cleanup controller
В учебном случае пользовательский ресурс ждёт ключ example.org/cleanup. Контроллер временно не работает, а внешняя задача ещё существует. После восстановления controller завершается подтверждённая очистка и ключ исчезает. Это пример механизма, а не описание установленного оператора. Если controller восстановить невозможно, составьте отдельный план ручного выполнения его обязанностей, проверяя реальное состояние внешних ресурсов до любых изменений метаданных.
| Проверка | Сохраняемое подтверждение |
|---|---|
| Кто поставил ключ | Документация и владелец controller |
| Что требуется очистить | Список реальных зависимостей |
| Почему действие не выполнено | События и журнал controller |
| Когда очистка завершена | Проверяемое конечное состояние |
Исправьте причину ожидания
Восстановите доступ controller к API и зависимости либо устраните объект, который законно блокирует очистку. Не запускайте массовое удаление finalizers по всему namespace. Если после выполненной ручной очистки требуется убрать конкретный ключ, запишите обоснование и точный объект. Kubernetes ограничивает изменение finalizers после начала удаления; добавить новый ключ или отменить deletionTimestamp обычным редактированием не получится. План должен учитывать, что удалённый объект потребуется создать заново, а не «вернуть из Terminating».
Проверьте отсутствие остаточных ресурсов
После исчезновения объекта API проверьте связанные записи, внешние задачи и оставшиеся зависимости. Завершённое удаление не равно доказанной очистке всех сторонних систем без их проверки. Артефакт расследования должен связывать UID, finalizer, владельца cleanup и подтверждённый результат. Для последующих повторений сохраните наблюдаемую причину, а не только команду удаления ключа. Такой протокол помогает восстановить контролируемый жизненный цикл вместо накопления скрытых ресурсов после формально успешного удаления.
Связанные разборы: cloud gpu resource cleanup audit; gpu exit plan.