Kubernetes 1.37 показывает, когда постоянный том перестал использоваться
Beta-функция добавляет PVC состояние Unused и время перехода. Контроллер отслеживает ссылки pod на хранилище и сохраняет результат в стандартном статусе.
Использование становится частью статуса PVC
Kubernetes описал переход PersistentVolumeClaimUnusedSinceTime в Beta в ветке 1.37. Подробная публикация вышла 21 сентября; функция включена по умолчанию для этой ветки. Контроллер защиты PVC добавляет условие Unused, показывающее, ссылается ли на заявку хотя бы один незавершённый pod. Раньше администратору часто приходилось самостоятельно сопоставлять списки pod, PersistentVolume и PVC. Сам PVC представляет заявку на хранилище, а PersistentVolume — ресурс с данными. Удаление приложения не обязано уничтожать его внешнее хранилище: это сознательное разделение жизненных циклов. Со временем остаются тома, текущее использование которых трудно определить по одному имени. Новое условие переносит это наблюдение в стандартный API.
Pending тоже считается использованием
Статус следует декларативному смыслу ссылки. Если хотя бы один работающий или ожидающий pod указывает PVC, Unused равно False с причиной PodUsingPVC. Даже pod, который не может быть размещён из-за невыполнимого условия планирования, выражает намерение использовать том. Завершённые pod с фазой Succeeded или Failed такой ссылкой статус не удерживают. Когда последний незавершённый потребитель исчезает или заканчивает работу, условие переходит в True с причиной NoPodsUsingPVC. Следовательно, это наблюдение за объектами Kubernetes, а не за физическим диском. Оно не зависит от того, читал ли запущенный процесс файл в последнюю минуту. Один том могут использовать несколько pod, и контроллер учитывает весь набор ссылок.
Метка времени и выключение функции
Как у остальных условий Kubernetes, у Unused есть lastTransitionTime. При переходе в неиспользуемое состояние оно фиксирует время события. По метке можно найти заявки, которые простаивают длительно, без собственного процесса сбора истории. KEP 5541 описывает feature gate со стороны API server и controller manager: для нового поведения нужны оба компонента. Если сервер не принимает новое условие, контроллер не сможет сохранить его как предусмотрено. При выключении функции записанное условие остаётся, но обновление прекращается. Статус после этого может устареть. Документ также описывает повторное включение и согласование наблюдения на последующих переходах. Это позволяет отделять сохранённое значение API от активной работы контроллера, который его поддерживает.
Наблюдение не меняет жизненный цикл данных
KEP подчёркивает информационный характер Unused: существующая защита используемого хранилища сохраняется, а другие контроллеры не получают приказ автоматически удалить том. Политика возврата PersistentVolume остаётся отдельной частью модели хранения. Состояние живёт в status PVC рядом с другими сведениями и доступно для панелей инвентаризации. В Beta добавлены сквозные проверки, а дальнейший переход в GA зависит от развития функции. При включении возможна дополнительная очередь оценки заявок; KEP описывает наблюдение за успешными и ошибочными обновлениями статуса. Дата освобождения и дата создания заявки дают разные сведения, и теперь их можно получить из соответствующих полей. Сентябрьское изменение расширяет наблюдаемость постоянного хранилища без объединения жизненного цикла приложения и его данных.
