Что такое PersistentVolume (PV) в Kubernetes
Что проверяют
Различаете ли вы сам ресурс хранилища и заявку на него, и понимаете ли, что состояние в Kubernetes живёт по другим правилам, чем поды. Вопрос входной: с него разворачивают разговор про StatefulSet, StorageClass и аварии с примонтированными дисками.
Как отвечать
PersistentVolume это объект уровня кластера, описывающий конкретный кусок хранилища: размер, режимы доступа, политику освобождения, драйвер CSI и параметры тома. PersistentVolumeClaim это заявка внутри пространства имён: приложению нужно столько-то места с такими режимами. Kubernetes связывает заявку со свободным томом один к одному, и под монтирует именно заявку, а не том напрямую.
Что стоит назвать:
- режимы доступа: ReadWriteOnce (том монтируется на один узел), ReadOnlyMany, ReadWriteMany (нужна сетевая файловая система), ReadWriteOncePod для строго одного пода;
- статическое выделение администратором против динамического через StorageClass;
- политика освобождения: Retain сохраняет данные после удаления заявки, Delete уносит том вместе с ней;
- режим связывания WaitForFirstConsumer: том создаётся после планирования пода, иначе диск может появиться в зоне, куда под не попадёт;
- расширение при allowVolumeExpansion, уменьшение не поддерживается.
Для приложений с состоянием применяют volumeClaimTemplates в StatefulSet: у каждого пода своя заявка со стабильным именем, переживающая пересоздание пода.
Где спотыкаются
Читают ReadWriteOnce как «один под». Режим про узел: два пода на одном узле том разделят, а на разных нет, и ровно на этом зависают обновления, пока старый под держит диск.
Ставят политику Delete на боевые тома, а потом удаляют пространство имён целиком. Данные уезжают вместе с заявкой, восстанавливать их неоткуда, если не настроены снимки или внешние копии.
Ждут, что заявка удалится по первой команде. Пока том примонтирован работающим подом, финализатор защиты держит объект в состоянии Terminating: сначала убирают потребителя, потом заявку, иначе картина выглядит как зависший кластер.