# Ресурс завис в Terminating: как диагностировать finalizer

Диагностика: Ресурс завис в Terminating: как диагностировать finalizer. Признаки, последовательность проверки, рабочий пример и критерии восстановления.

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

Зависший Terminating ресурс с finalizer обычно ждёт завершения предусмотренной очистки. Сначала найдите контроллер и зависимые объекты. Ручное удаление ключа finalizer может убрать объект API, оставив реальные ресурсы и нарушенные зависимости, поэтому это не универсальное исправление.

## Сохраните метаданные удаления

Получите deletionTimestamp, finalizers, ownerReferences, UID и события объекта. Сравните состояние владельца и потомков. Finalizer — это ключ, на который реагирует контроллер, а не текст исполняемой команды внутри объекта. Выясните, какой компонент должен выполнить cleanup и убрать ключ. Состояние Terminating может сохраняться при недоступном контроллере, отказе внешней зависимости или действительно незавершённом использовании ресурса. Разные причины требуют разных действий и разных подтверждений выполненной очистки.


[Официальный источник 1](https://kubernetes.io/docs/concepts/overview/working-with-objects/finalizers/).

## Проследите зависимость до владельца

При foreground и background deletion порядок удаления связанных объектов различается. Owner reference помогает понять каскад, но не заменяет назначение конкретного finalizer. Для volume protection ожидаемое поведение может состоять в сохранении объекта, пока его использует Pod. Удаление finalizer в таком случае скрывает защиту, а не восстанавливает controller. Проверьте также namespace и идентификаторы: новый объект с прежним именем не обязательно является владельцем старой зависимости из-за другого UID.


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

## Разберите отказ 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](/ru/journal/cloud-gpu-resource-cleanup-audit/); [gpu exit plan](/ru/journal/gpu-exit-plan/).